Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Fri, 28 August 2015 18:56 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA501B2E93 for <tcpinc@ietfa.amsl.com>; Fri, 28 Aug 2015 11:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Level:
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001, 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 cpfJF8YxT6Aj for <tcpinc@ietfa.amsl.com>; Fri, 28 Aug 2015 11:56:48 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 A9BBD1B2EB0 for <tcpinc@ietf.org>; Fri, 28 Aug 2015 11:56:48 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id t7SIumZ4029725; Fri, 28 Aug 2015 11:56:48 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7SIukDJ031699; Fri, 28 Aug 2015 11:56:46 -0700 (PDT)
X-Authentication-Warning: market.scs.stanford.edu: dm set sender to dm-list-tcpcrypt@scs.stanford.edu using -f
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: Eric Rescorla <ekr@rtfm.com>
In-Reply-To: <CABcZeBPVhQ-nJw4zjELXeU8LwhkyMGxi3gEROaEa0iTsjt=y4g@mail.gmail.com>
References: <CABcZeBNEFVkDi38y3G-C2nQF=dzW2mGDsj5DVK_OKVkPwK=G0g@mail.gmail.com> <878u92oadf.fsf@ta.scs.stanford.edu> <CABcZeBMfk5C4-LF0fDLKpJktV3hJyzRUNfe0gO8RYDnzcs3yMA@mail.gmail.com> <87zj1inf7n.fsf@ta.scs.stanford.edu> <CABcZeBMZCjrwpTH+CkZS_p8TYGEFsXwxGn=KfPe28hY5f=2oXw@mail.gmail.com> <87oahuta7j.fsf@ta.scs.stanford.edu> <CABcZeBPiUxByxUVJ3cb5LaeH5T1LX3iZFetP4cXM3O9avzBkCA@mail.gmail.com> <87si75jo4s.fsf@ta.scs.stanford.edu> <BDF93B3E-9DE0-4FEA-A4A7-6E6A69E4169B@tik.ee.ethz.ch> <87h9nkkcqc.fsf@ta.scs.stanford.edu> <55DF25DC.2040001@tik.ee.ethz.ch> <87twrkhfpg.fsf@ta.scs.stanford.edu> <CAJU8_nWktUwni0=nywx-bbHg+j_K5GWFAZD8g3ZbKx7GLk4jpQ@mail.gmail.com> <877fogvdq7.fsf@ta.scs.stanford.edu> <CABcZeBPTGQvjdP7-6=+mN0S6wWOZC8PrsZhGu85NMkFQF-nMXg@mail.gmail.com> <8737z3kijy.fsf@ta.scs.stanford.edu> <CABcZeBPVhQ-nJw4zjELXeU8LwhkyMGxi3gEROaEa0iTsjt=y4g@mail.gmail.com>
Date: Fri, 28 Aug 2015 11:56:46 -0700
Message-ID: <87h9nji6mp.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/wwfaBbp25lNbki7n-x1V211otcI>
Cc: tcpinc <tcpinc@ietf.org>, Kyle Rose <krose@krose.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Mazieres expires 2015-11-26 PST <mazieres-gtke622igq4ptstm76t3w75cjs@temporary-address.scs.stanford.edu>
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2015 18:56:49 -0000

Eric Rescorla <ekr@rtfm.com> writes:

>> With RFC6544, could the controlling/controlled roles be used to break
>> ties?  E.g., with TCP-ENO, could the controlling peer just always set
>> b=1?
>
>
> The problem is that there are situations where each side thinks it is
> controlling
> ("role conflicts"). RFC 5245 has the tiebreaker field to resolve this.

But isn't the tie broken before probing the candidate addresses?  I
thought the tie breaker was something that went in an SDP message or
something?  With respect to figure 12 in RFC5245, I was assuming the tie
breaker was sent in SDP1 or SDP2, which would occur before the TCP-SO.
But I admit I'm not very knowledgeable about ICE.

Anyway, it's entirely possible that ICE could make setting the b bit a
pain, where a revised protocol could solve this problem (e.g., the
controller that causes this role conflict in the first place could just
assign the b bit).  But since as you say, ICE itself doesn't want
TCPINC, this isn't a big deal.

Really, the goal of the "b" bit was just that if an application cares
enough to break the tie out of band, it should be able to use TCPINC
with TCP-SO.  In this sense, TCP-ENO is shooting for a pretty minimal
goal, but at a pretty minimal cost as well (namely one bit).  At a
higher level, we both agree "don't worry too much about SO".

David