From nobody Wed Apr 2 00:55:04 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CFD1A00CF for ; Wed, 2 Apr 2014 00:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 6yP-YmmJWflr for ; Wed, 2 Apr 2014 00:54:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0291A001B for ; Wed, 2 Apr 2014 00:54:56 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 194182780FE for ; Wed, 2 Apr 2014 16:54:49 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id pv20so7724947lab.24 for ; Wed, 02 Apr 2014 00:54:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nWbWty2CypU4y+Zl7AFYmKL/e6fYRGjbo6nUxO0oNXg=; b=TpACWrxTjP4zkz3NSYEaVBoHU/9mkI08UAa3geb8aXZA3MKNIs0nDl4c/QzVAiBwoa FQyFciXVuogvNxtk03HQld3QPm4KRqL52CyrOLX9vx63yekU88poC2XraduJqDO/kNxe EE6UwW9XRh/6VRw5dSUAH1+LSNvug6c+mHLw3zQz4SHsJYxLuqqtqtfe00Djvn3nKrKM s9UO98jpb+VSIP2cjVJc5oWNIhKhFD2dMFXoepcz+QvaW87OFzE1YtInTNP9e3/HuBVW wGwGmusYnEdms7BAPd6ZlYqcHBkvy5/zlJiottPhhv3HLxctxDUYNJa1/tGa9QIKuGoa NrZg== MIME-Version: 1.0 X-Received: by 10.152.36.73 with SMTP id o9mr989258laj.30.1396425287135; Wed, 02 Apr 2014 00:54:47 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Wed, 2 Apr 2014 00:54:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Apr 2014 00:54:47 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/ZVV8tiEN7NYgRCInS9jzDC3O71A Subject: Re: [multipathtcp] WGLC for draft-ietf-mptcp-attacks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 07:55:01 -0000 Hi, I have read draft-ietf-mptcp-attacks-00.txt. Please check my comments below. Also, please point out if I miss something. Technical Comments: 1: As described in Section 7, we have an intention to archive the same security level as RFC5061. However, if we adopt 1) enhancement, the security level will be lower than this. Hence, I think we cannot recommend this. Similarly, if MPTCP MUST work through NATs, I think we cannot recommend 3) and 4) enhancements. From these reasons, I'm wondering if we really need to have 1), 3) and 4) enhancements in Section 2.1. At least, I prefer to have some texts that they are not recommended in order to be consistent. 2: In 2) enhancement in section 2.1, it seems that HMAC will be created with the key of the receiver of the ADDR_ADDR message. Is there any reason that the key of the sender is not used here? I think the HMAC in MP_JOIN uses both keys. 3: In 3) enhancement in section 2.1, I might miss something, but I couldn't see the security benefits to include the destination address of the message in the HMAC as attackers can get this info. 4: In 4) enhancement in section 2.1, I'm not sure why we want to utilize MP_JOIN message here. I think you might want to put more texts here. 5: In Section 5, 5 possible enhancements include TCPCrypt are simply listed. However, in Section 7, it is mentioned that TCPCrypt seems a promising one. Is there any reason behind this? Editorial Comments: 1: Section 3, I think we don't need to put '?' in the threat level. Also, it seems that "(as it is hard..)" sentence is not necessary as it is described in the description. 2: Section 3, "This, because" -> This is because 3: Section 4.1, "(like 3)" -> I think you mean "(as described in Section 3.1)" 4: Section 6.1, NATS -> NATs 5: Section 7, SCPT -> SCTP 6: Section 7, "Security enhancements for MPTCP" -> I think this is subsection title. If so, please provide the section number. Regards, -- Yoshi On Thu, Mar 27, 2014 at 9:41 PM, Yoshifumi Nishida wrote: > Hello, > > As mentioned in the London meeting, we start WGLC on draft-ietf-mptcp-attacks. > The WGLC will run until * April 14th *. The intended status of the > document is Informational. > > Please provide your feedback to the ML before the deadline. > The draft is available at: > http://tools.ietf.org/html/draft-ietf-mptcp-attacks-00 > > Regards, > -- > Yoshi & Phil From nobody Wed Apr 2 11:46:28 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B931A0383 for ; Wed, 2 Apr 2014 11:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.211 X-Spam-Level: X-Spam-Status: No, score=-104.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 zYAZMVjDsl-U for ; Wed, 2 Apr 2014 11:46:21 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 10DEC1A037B for ; Wed, 2 Apr 2014 11:46:20 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 67E0CCB7E8C for ; Wed, 2 Apr 2014 20:46:16 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (15.111.220.87.dynamic.jazztel.es [87.220.111.15]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 31396C32BBD for ; Wed, 2 Apr 2014 20:46:16 +0200 (CEST) Message-ID: <533C5AF5.7080505@it.uc3m.es> Date: Wed, 02 Apr 2014 20:46:13 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: multipathtcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20604.007 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/z_RvVu-18ZuQLqT-TN-VXDJg-i4 Subject: Re: [multipathtcp] WGLC for draft-ietf-mptcp-attacks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 18:46:26 -0000 thanks for the review. I will address the comeents soon El 02/04/14 09:54, Yoshifumi Nishida escribió: > Hi, I have read draft-ietf-mptcp-attacks-00.txt. > Please check my comments below. Also, please point out if I miss something. > > > Technical Comments: > > 1: As described in Section 7, we have an intention to archive the same > security level as RFC5061. > However, if we adopt 1) enhancement, the security level will be > lower than this. Hence, I think we cannot recommend this. > > Similarly, if MPTCP MUST work through NATs, I think we cannot > recommend 3) and 4) enhancements. > From these reasons, I'm wondering if we really need to have 1), 3) > and 4) enhancements in Section 2.1. > At least, I prefer to have some texts that they are not recommended > in order to be consistent. > > 2: In 2) enhancement in section 2.1, it seems that HMAC will be > created with the key of the receiver of the ADDR_ADDR message. > Is there any reason that the key of the sender is not used here? I > think the HMAC in MP_JOIN uses both keys. > > 3: In 3) enhancement in section 2.1, I might miss something, but I > couldn't see the security benefits to include the destination address > of the message in the HMAC as attackers can get this info. > > 4: In 4) enhancement in section 2.1, I'm not sure why we want to > utilize MP_JOIN message here. > I think you might want to put more texts here. > > 5: In Section 5, 5 possible enhancements include TCPCrypt are simply listed. > However, in Section 7, it is mentioned that TCPCrypt seems a > promising one. Is there any reason behind this? > > > Editorial Comments: > > 1: Section 3, I think we don't need to put '?' in the threat level. > Also, it seems that "(as it is hard..)" sentence is not necessary > as it is described in the description. > > 2: Section 3, "This, because" -> This is because > > 3: Section 4.1, "(like 3)" -> I think you mean "(as described in Section 3.1)" > > 4: Section 6.1, NATS -> NATs > > 5: Section 7, SCPT -> SCTP > > 6: Section 7, "Security enhancements for MPTCP" -> I think this is > subsection title. If so, please provide the section number. > > Regards, > -- > Yoshi > > > On Thu, Mar 27, 2014 at 9:41 PM, Yoshifumi Nishida > wrote: >> Hello, >> >> As mentioned in the London meeting, we start WGLC on draft-ietf-mptcp-attacks. >> The WGLC will run until * April 14th *. The intended status of the >> document is Informational. >> >> Please provide your feedback to the ML before the deadline. >> The draft is available at: >> http://tools.ietf.org/html/draft-ietf-mptcp-attacks-00 >> >> Regards, >> -- >> Yoshi & Phil > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From nobody Tue Apr 8 08:03:46 2014 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865531A0337; Tue, 8 Apr 2014 08:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.878 X-Spam-Level: X-Spam-Status: No, score=0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 jXMqbpxbh4lC; Tue, 8 Apr 2014 08:03:37 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 260431A03BA; Tue, 8 Apr 2014 08:03:36 -0700 (PDT) Received: from kringsjaa.localnet ([158.39.4.2]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id s38F3Ykc011811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Apr 2014 17:03:35 +0200 From: Thomas Dreibholz To: iccrg@irtf.org, multipathtcp@ietf.org, rserpool@ietf.org Date: Tue, 08 Apr 2014 17:03:34 +0200 Message-ID: <2378178.GQ3YpeXhD0@kringsjaa> User-Agent: KMail/4.13 rc (Linux/3.13.0-23-generic; KDE/4.12.97; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4836184.1xk5zWR9RY"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/8WYYCmCj63QZ0Vn4ozPn6CMQYWA Subject: [multipathtcp] PAMS 2014 Call for Participation X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 15:03:42 -0000 --nextPart4836184.1xk5zWR9RY Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" [Our apologies if you receive multiple copies of this message.] CALL FOR PARTICIPATION We cordially invite you to join us at: The 4th International Workshop on Protocols and Applications with Multi-Homing Support (PAMS 2014) In conjunction with the 28th IEEE International Conference on Advanced Information Networking and Applications (AINA 2014) Victoria, BC/Canada, May 13-16, 2014 https://simula.no/pams2014 The intent of our workshop is to bring together people from research and industry, in order to provide a discussion forum for state-of-the-art topics related to multi-homing on Network, Transport, Session and Application Layers. Further details are available at: https://simula.no/pams2014 We are looking forward to see you in Victoria, BC/Canada! The PAMS 2014 Chairs --nextPart4836184.1xk5zWR9RY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlNED8YACgkQ32BbsHYPLWUQWgCdGGXhG8yS1mhtZzya/hPZ0PZS yocAn3oeeeXQyeDO8CMar+3TAuJUDh7Q =PBX+ -----END PGP SIGNATURE----- --nextPart4836184.1xk5zWR9RY--