IETF Logo Mail Archive

Re: [multipathtcp] standards track now

Roberto Peon <grmocg@gmail.com> Fri, 02 August 2013 06:13 UTC

Return-Path: <grmocg@gmail.com>
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 D93CD11E8221 for <multipathtcp@ietfa.amsl.com>; Thu, 1 Aug 2013 23:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCEBFcgcpEkv for <multipathtcp@ietfa.amsl.com>; Thu, 1 Aug 2013 23:13:43 -0700 (PDT)
Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id CB18911E824E for <multipathtcp@ietf.org>; Thu, 1 Aug 2013 23:13:37 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id j6so571562oag.28 for <multipathtcp@ietf.org>; Thu, 01 Aug 2013 23:13:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v0dwBvf/0POQ+VhlwVR1r+1cad9B6jQwYqA8ZiFmfFU=; b=oWqmcDq3XWkt1kbRMWFl5BThzuIx/hLKaMlgzdSe/vD9iIyL69qPvXpZQ2RvA++DKe Ysd76Yqu0DGqVYTydlVVmjtIc/YPBWQKPrDGyj8l3MQXc0/HAb10ZfLNe68v6F/+uURq E77DnfUDnTzXQt2ZZrR3TnM0dgrb/deYx1HcZUyr9x6s020u1tksPaKU2LYMRCNUvwbi J+f2KV5U82Z/Mk8xky/qbnIzEFx/Wiwn0NGz0X14I4H7vekwogslezAUd2BaLabS1yC9 PaFHZVbHTceT0ZeT8zp8MSl4OtPcbHiIoiLWAByE6XMahzSon6kfKTZtWSBrbV84WroV VsVw==
MIME-Version: 1.0
X-Received: by 10.60.45.38 with SMTP id j6mr4024572oem.56.1375424017373; Thu, 01 Aug 2013 23:13:37 -0700 (PDT)
Received: by 10.76.91.229 with HTTP; Thu, 1 Aug 2013 23:13:37 -0700 (PDT)
In-Reply-To: <CAO249yeWyOZd0Hx-s7EO73xY-ymCjMNMQ062L8vv9pt18zxhTg@mail.gmail.com>
References: <86D5F8DA-93EE-4F17-BBCE-C61F410829AE@netapp.com> <51FA1504.6030001@internet2.edu> <CAO249yeWyOZd0Hx-s7EO73xY-ymCjMNMQ062L8vv9pt18zxhTg@mail.gmail.com>
Date: Fri, 02 Aug 2013 08:13:37 +0200
Message-ID: <CAP+FsNcQNK-BjwG8ROUgFLDRVa4fpf+quyWffp-D-_FtLO_03Q@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Content-Type: multipart/alternative; boundary="089e015367ecf89d0f04e2f0db64"
Cc: Multipath TCP Mailing List <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] standards track now
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 02 Aug 2013 06:13:44 -0000

Similar vulnerabilities exist for SCTP.
When SCTP was defined these attacks were far more theoretical than the
attacks we're seeing done today.

Analogies about jumping off of bridges because someone else did come to
mind... :)
-=R


On Thu, Aug 1, 2013 at 9:15 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>wrote:

> Hi folks,
>
> Since I couldn't attend the meeting, I might miss something, but anyway..
> For (2), we have SCTP which already has similar feature for ADD_ADDR.
> It's well designed and has been used for a while. And RFC5061 is PS.
> I'm wondering how MPTCP is vulnerable compared to SCTP and how much
> protection we'll need.
>
> Thanks,
> --
> Yoshifumi
>
> On Thu, Aug 1, 2013 at 12:57 AM, Scott Brim <swb@internet2.edu> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 08/01/13 09:43, Eggert, Lars allegedly wrote:
> >> Hi,
> >>
> >> as I just said during TSVAREA, I think we should recharter the WG
> >> to allow work on a PS spec now.
> >>
> >> The issues that remain to be worked on a clearly tractable and can
> >> be resolved during the normal process of pushing an ID towards RFC
> >> publication.
> >>
> >> Lars
> >
> > I'm going to be the person who says "let's not be hasty".
> >
> > (1) A fundamental point in MPTCP is balancing traffic on subflows and
> > overall coordinated congestion management.  Ramin Khalili's
> > presentation showed that what we have so far seems pretty
> > experimental, and we're essentially still at the research stage.
> >
> > (2) NATs are real, so ADD_ADDR is going to get used, but it's a
> > security hole.  That's "clearly tractable" but what we have now is not
> > ready for even limited deployment.  Maybe ADD_ADDR should be taken out
> > of the standards track docs and added later.
> >
> > Scott
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.13 (Darwin)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iEYEARECAAYFAlH6FQQACgkQF0TR2hENFARCdACfVOVd1qXv0bnB5LJEOTqNJ4BD
> > BmkAn0Au+FfCvkURa1AlxFVfvbE0mNlK
> > =POc0
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > multipathtcp mailing list
> > multipathtcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

v2.23.0 | Report a Bug | By Email