Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

Brian Trammell <ietf@trammell.ch> Fri, 29 July 2016 12:36 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21D412D50C for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 05:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level:
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, 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 039zMq1sA0Bm for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 05:36:21 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2429F12D1EB for <spud@ietf.org>; Fri, 29 Jul 2016 05:36:21 -0700 (PDT)
Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 710D41A13A3; Fri, 29 Jul 2016 14:35:50 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_34D0050B-7228-4011-B88A-CC53D8D365D0"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <89CE79B8-0FA3-424D-9184-B202A4BD380E@trammell.ch>
Date: Fri, 29 Jul 2016 14:35:49 +0200
Message-Id: <C7EB8DD5-F1E8-4670-9DB4-9D63DC738C24@trammell.ch>
References: <CAKC-DJjVF_mQb49BJmHNpt-VkJSX6JHXH8hTbYMm2bEYg3rgwA@mail.gmail.com> <E8355113905631478EFF04F5AA706E9831045CD8@wtl-exchp-2.sandvine.com> <CAKC-DJiKynAhrodZLvvGB62u19TTxr5BxT6RkS8OOOUAurWcZA@mail.gmail.com> <89CE79B8-0FA3-424D-9184-B202A4BD380E@trammell.ch>
To: Erik Nygren <erik+ietf@nygren.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/gy0Unr05AMbXB7ydM4kqn7o9GHg>
Cc: Kyle Rose <krose@krose.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Dave Dolson <ddolson@sandvine.com>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2016 12:36:24 -0000

Greetings, all,

Oops, somehow GPGTools decided that message needed to be encrypted. Here it is so that everyone can read it:

> On 29 Jul 2016, at 12:57, Brian Trammell <ietf@trammell.ch> wrote:
> 
> hi Erik, all,
> 
> Still catching up on threads here. One point inline:
> 
>> On 28 Jul 2016, at 17:56, Erik Nygren <erik+ietf@nygren.org> wrote:
>> 
>> This is exactly the sort of thing that I think demonstrates the value of defining something here so we can have one mechanism that a bunch of UDP protocols can use to allow for several minute state timeouts.
>> 
>> With TCP you need the sequence/ack numbers to get enough entropy due to the port number being only 16 bits.  If the connection-id is 64 bits (or there are two 64-bit connection-ids in the packet, one contributed by each end-point) does this contribute enough entropy to prevent passive adversary close/reset attacks?  It seems like active adversary close/reset attacks aren't possible to reliably defend against (without crypto between middle boxes and endpoint).
> 
> See Luckie et al in IMC2015 "Resilience of Deployed TCP to Blind Attacks" at http://www.caida.org/~mjl/pubs/blind.pdf. Summary: the situation is pretty bleak for everything except BGP. The dominance of relatively short TCP sessions in Internet traffic mitigates this somewhat.
> 
> An explicit separation between integrity-protected, path-visible, and confidentiality-protected, path-invisible communication in the transport layer is necessary to remedy this situation. This is of course what we're trying to do here. :)
> 
> Cheers,
> 
> Brian
> 
>> A pattern that has been discussed that seems quite valuable would be to distribute additional connection-ids for mobility and resumption within the encrypted channel.  This would allow for resumption, mobility, and periodically cranking the connection-id without linkability.
>> 
>> Having a server-contributed component of the connection-id (perhaps an initial one in clear-text and later ones through the encrypted channel) could allow for stateless packet distribution by server-side load balancers and could also form part of a proof-of-address-ownership three-way-handshake mechanism to mitigate against DDoS reflection and spoofed source address attacks.
>> 
>>      Erik
>> 
>> 
>> 
>> On Thu, Jul 28, 2016 at 11:23 AM, Dave Dolson <ddolson@sandvine.com> wrote:
>> Regarding the state kept by middle-boxes such as firewalls:
>> 
>> The timeout should be short (a few seconds) until a three-way handshake is complete. This is required to defend against attacks on state memory of the firewall.
>> 
>> 
>> 
>> In the three-way handshake:
>> 
>> - The server’s SYN-ACK indicates the server is real and willing to talk to the client.
>> 
>> - the client’s ACK of the server’s SYN-ACK provides evidence the client is real (vs. spoofed) and has witnessed the SYN-ACK
>> 
>> 
>> 
>> The random sequence numbers and ack numbers are valuable in this regard. E.g., a spoofing device cannot simply send the first and third packets because the third packet must correctly ACK the second packet from the server.
>> 
>> 
>> 
>> Once a three-way handshake is witnessed, TCP state timeout can be several minutes.
>> 
>> 
>> 
>> The proposal below doesn’t seem to contain enough information for a firewall to know the client is real.
>> 
>> Consider adding a random number that each side can echo back? Perhaps a different connection-ID per direction?
>> 
>> 
>> 
>> -Dave
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Erik Nygren
>> Sent: Thursday, July 28, 2016 11:03 AM
>> To: Mirja Kühlewind
>> Cc: Kyle Rose; spud@ietf.org
>> Subject: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)
>> 
>> 
>> 
>> On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
>> 
>> As mentioned by Ted, this is actually not what we propose. The mechanism we propose is exposing information under endpoint control which is a very important point here. The endpoint has to add an option to send (or request) a specific bit of information (which also must be registered by IANA with IESG approval). This is just the same as TCP options or IP option headers. The only difference is that PLUS has a MAC which allows detection of middlebox manipulation (which is not the case for other existing protocols such as TCP options). This is another a very big and important aspect of what we propose with PLUS as our goal is to encrypt everything above PLUS including the TCP header and TCP options in future. Especially encrypting TCP option is important because TCP options provide much less control than what we propose with PLUS today which is a problem (especially as currently still unto 90% of the traffic is TCP). So I actually though we are on the same page here and have a common goal.
>> 
>> 
>> 
>> I'm not sure that we get enough value out of extensibility or being overly generic here, at least for practical non-research purposes.  If there is a tightly defined set of things allowed, we'll quickly ossify on these anyways.  As firewall vendors will just bake in those registered by IANA when they ship their product and then we'll be right back where we are today with IPv6 extension headers.
>> 
>> I'd propose that it may make more sense to define a fixed header prefix format that contains the right set of features needed to solve the problems of QUIC and WebRTC (and other future UDP protocols).  Along with this, also define a common set of requirements for protocols using this header prefix (eg, around DDoS reflection prevention).
>> 
>> Having a toolkit for things like handling connection ids in a way that support multipath mobility, stateless load-balancers, DDoS resiliance, and which minimize linkability would also be a nice-to-have to prevent each UDP protocol from having to come up with subtly different ways to solve this set of problems.
>> 
>> 
>> 
>> For example, a bare minimum set of features might include:
>> 
>> 
>> 
>> * Opportunistic signalling to middle-boxes (NATs and Firewalls) for when they can discard connection state.  Unless we want to declare that new UDP protocols only work with IPv6 (worth seriously considering, but perhaps not realistic yet), there just aren't enough {IPv4,port} tuples available for NATs to support large numbers of users with large numbers of UDP connections without having crazy-short keep-alive lifetimes.  Middle-boxes will always need to be aware that this is best-effort (the FINs can be dropped or lost or not sent by malicious clients, especially during multipath transitions) but this could make life much better for well-behaved clients and things like the existing NATs which use port ranges per client might encourage clients to be well-behaved here on average.
>> 
>> * Negotiating initial PMTU/MSS.  While clients will need to be able to probe up/down and respond to routing changes that change the PMTU, the TCP MSS mechanism and ability for middle boxes to decrement/clamp this value makes a big difference  in how quickly clients behind tunnels can converge without losing round-trips or having very complicated probing.  Especially if we want to be able to deploy jumbo-frames it will be important to have a mechanism here.
>> 
>> 
>> 
>> * Sending signals in both directions that can be correlated to connections.  Using ICMP/ICMPv6 may be a fine way to do this but having a common prefix for connection information that can be included in the message makes some things such as routing the messages through a load-balancer much more viable).
>> 
>> 
>> 
>> * ... there may be a few others from the use-cases doc.
>> 
>> 
>> 
>> Having a fixed header prefix format might also make it much more viable to implement with today's router/firewall hardware with just firmware/software updates which might make a big difference for medium-term uptake.
>> 
>> It might be we can get away with something like:
>> 
>>   [MAGIC+VERSION] [CONNECTION_ID] [BITS_FOR_SYN_FIN]
>>   [MSS_DURING_NEGOTIATION_WHEN_SYN_IS_SET]
>> 
>>   [EXTENSION_SPACE_OSSIFICATION_MAY_NOT_PASS]
>> 
>> 
>> 
>> It might be reasonable to allow for some padding space for future extension and research, but with the expectation that this will often get dropped/filtered and thus would be something clients would need to probe for (and is something people could find a way to do today regardless).
>> 
>> 
>> 
>>    Erik
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Spud mailing list
>> Spud@ietf.org
>> https://www.ietf.org/mailman/listinfo/spud
>