Re: [Spud] States in draft-trammell-plus-statefulness-00

"Christian Huitema" <huitema@huitema.net> Mon, 14 November 2016 17:27 UTC

Return-Path: <huitema@huitema.net>
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 9EE5A12940D for <spud@ietfa.amsl.com>; Mon, 14 Nov 2016 09:27:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 dc1BPI-HvHtX for <spud@ietfa.amsl.com>; Mon, 14 Nov 2016 09:27:50 -0800 (PST)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 6EC071298A4 for <spud@ietf.org>; Mon, 14 Nov 2016 09:21:19 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1c6KwV-0005dQ-GL for spud@ietf.org; Mon, 14 Nov 2016 18:21:18 +0100
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1c6KwQ-0003Jx-TJ for spud@ietf.org; Mon, 14 Nov 2016 12:21:14 -0500
Received: (qmail 9871 invoked from network); 14 Nov 2016 17:21:10 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[208.54.39.200]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ddolson@sandvine.com>; 14 Nov 2016 17:21:09 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'Brian Trammell' <ietf@trammell.ch>, 'Dave Dolson' <ddolson@sandvine.com>
References: <E8355113905631478EFF04F5AA706E9831159645@wtl-exchp-2.sandvine.com> <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch>
In-Reply-To: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch>
Date: Mon, 14 Nov 2016 09:21:05 -0800
Message-ID: <03b101d23e9b$7c883540$75989fc0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKf862m8oZQa9APzsImua+wBtT6LQEXHGdBnzSPuEA=
Content-Language: en-us
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dNEAmMBmHDUmmY+3eqwn6k80HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD7FL knUxWH0C4yisWo0g2KibTEgoa6PTvhjKOiVft2q6dcmtTcWSOKD5RASVzg27isAXVRQgHbLLzV7b 3SwTZqt5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdc1pXJXxpAbEqfV7bN3pyp/i885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suok2jmyqSBZG+RxUC8CBX34LAZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVKnG+eTs8kbKBy2XcsLzqKfmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV6YO2/mqpOb7Q80SeXyngcEZA0ovkdUHlhxng/6M5IV+I73x9yTpqy088VxyqIsKLEe bp9tI6dJK7GvNGOBzee8
X-Report-Abuse-To: spam@mx99.antispamcloud.com
X-Originating-IP: 168.144.250.232
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.22)
X-Classification: unsure/combined
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/W6EBIkalfUQblj8_Uc1tZVuLrsU>
Cc: hildjj@cursive.net, mirja.kuehlewind@tik.ee.ethz.ch, spud@ietf.org
Subject: Re: [Spud] States in draft-trammell-plus-statefulness-00
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: Mon, 14 Nov 2016 17:27:52 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday, November 13, 2016 5:56 PM, Brian Trammell wrote:
>...
> Not yet defined; I'll be talking about this in QUIC tomorrow; see also my slides for that talk at 
> https://www.ietf.org/proceedings/97/slides/slides-97-quic-flow-state-signaling-and-quic-00.pdf

The basic connection state machine can be informed by arrival of packets in either direction and timeouts. This is indeed how most NAT handle UDP today, and it is independent of the protocol on top of UDP. It is also fairly robust to route changes, as the new traffic will naturally open the flows in the new route. The main drawbacks come from the use of timers. Too long and they use too much resource in the middle, too short and they require inefficient keep-alive traffic. On the other hand, since endpoints may well just drop off a route without notice, we know that timers are needed in any case. So, we could frame the problem simply as "can we find an alternative to timers for state management." 

My preference would be for standardizing some well-known magic packets with meanings like "keep me alive for another N minutes" or "drop me now", and to rely on bidirectionality to avoid vulnerability to spoofing attacks. Then, the onus would be on end to end protocol to incorporate or work around these magic packets.

The natural temptation is to go analyze the end-to-end protocol, but it can lead to complex code and ossification. I really wonder whether PLUS should do specific work for QUIC, by opposition to "generic work applicable to any UDP based protocol."  I am concerned that implementing protocol-specific logic in the middle of the network leads to ossification of that protocol, and in fact we saw hints of that with boxes that tried to recognize the version number field in QUIC. When the version number changes, these boxes detected an error and started blocking packets. Of course, this was incorrect behavior, but ossification precisely starts there, incorrect behavior distributed all around the network. 

The other concern is that if all the logic is protocol specific, then you need different logic for QUIC, DTLS, RTP, COAP and what have you. This makes the boxes more complex and more error prone, not to mention potential attack surface if these boxes attempt to parse complex protocols. Also, it creates another form of ossification, in which it becomes very hard for our grandchildren to develop the successor to QUIC.

- -- Christian Huitema



-----BEGIN PGP SIGNATURE-----
Comment: Using gpg4o v5.0.7.7563 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJYKfKAAAoJELba05IUOHVQU4gH/1I/NvN86/3tXcQerkE0+m0w
AnqbBSWcnOVc2S37xBZcdVq28iDzOjrCIZPChJeMGmsKWSXE7Zehp2qGXWJn7h8x
jmGsR9MoCtoN4sG87kYfM+QPlZACEQggBolm8InkFHqFT4EbIQJcnyevTtmH2Hx1
uFgpj7wdD2UxV5UWW0syhc4nHI7BJ8o5WQ8pVj+Ve++xP8vBsdeO0+JZdtcKHMPM
pPVAEfzcb4hnEfI4/Xw+cSK0h2X7ncKeOfBuPA7tKMcrNWlJqcEHZ7hT9iZOfifY
WQfGy7U5vjKMQB1rdCRHoOCzlqTxEtfSCTGirmmZjsKq2qQgY2wMAHDjemR2YMk=
=cZq+
-----END PGP SIGNATURE-----