From nobody Fri Nov 11 02:55:40 2016 Return-Path: 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 D05F2129639 for ; Fri, 11 Nov 2016 02:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497] 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 bz-S4VV_Tn_0 for ; Fri, 11 Nov 2016 02:55:36 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A92D129660 for ; Fri, 11 Nov 2016 02:55:36 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Fri, 11 Nov 2016 05:55:35 -0500 From: Dave Dolson To: "mirja.kuehlewind@tik.ee.ethz.ch" , "hildjj@cursive.net" , "ietf@trammell.ch" Thread-Topic: States in draft-trammell-plus-statefulness-00 Thread-Index: AdI7o1fE+iaNGCadS5OC9ubAYOjCyQ== Date: Fri, 11 Nov 2016 10:55:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9831159645wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 10:55:38 -0000 --_000_E8355113905631478EFF04F5AA706E9831159645wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mirja, Brian, Joe, I think it is an interesting idea to formalize/standardize the state machin= e that should be used by flow-stateful network equipment. But having read about the four states and three timeouts, I feel you are mi= ssing a state after biflow that represents a fully proven connection. I'm thinking of the problem of source-spoofed SYN attack packets that attem= pt to consume state memory in servers and flow-stateful network devices. A network device may see client SYN and server SYN-ACK but never the comple= ted 3-way handshake because the client is not real. Until the 3-way handshake is completed, only short timeouts should be used.= This is true for server as well as stateful network devices. The nice thing about the client's ACK of the server's SYN flag is that it e= choes back (in the ACK field) the SYN sequence number, which is unlikely to= be guessed by an attacking node that doesn't own the address it used in th= e SYN packet. The ACK packet also carries the original client sequence# + 1= , proving it has a stateful connection. As an alternative to adding a state, you could enter the bi-flow state only= when the TCP 3-way handshake is complete. Does QUIC carry a network-observable signal indicating receipt of the serve= r packet? -Dave --_000_E8355113905631478EFF04F5AA706E9831159645wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mirja, Brian, Joe,

 

I think it is an interesting idea to formalize/stand= ardize the state machine that should be used by flow-stateful network equip= ment.

 

But having read about the four states and three time= outs, I feel you are missing a state after biflow that represents a fully p= roven connection.

 

I’m thinking of the problem of source-spoofed = SYN attack packets that attempt to consume state memory in servers and flow= -stateful network devices.

A network device may see client SYN and server SYN-A= CK but never the completed 3-way handshake because the client is not real.<= o:p>

 

Until the 3-way handshake is completed, only short t= imeouts should be used. This is true for server as well as stateful network= devices.

 

The nice thing about the client’s ACK of the s= erver’s SYN flag is that it echoes back (in the ACK field) the SYN se= quence number, which is unlikely to be guessed by an attacking node that do= esn’t own the address it used in the SYN packet. The ACK packet also carries the original client sequence# + 1, proving= it has a stateful connection.

 

As an alternative to adding a state, you could enter= the bi-flow state only when the TCP 3-way handshake is complete.

 

Does QUIC carry a network-observable signal indicati= ng receipt of the server packet?

 

-Dave

 

--_000_E8355113905631478EFF04F5AA706E9831159645wtlexchp2sandvi_-- From nobody Sun Nov 13 17:51:19 2016 Return-Path: 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 C0464129593 for ; Sun, 13 Nov 2016 17:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 Cb9IrY2534Sp for ; Sun, 13 Nov 2016 17:51:14 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 70840129474 for ; Sun, 13 Nov 2016 17:51:14 -0800 (PST) Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id B3BD61A058D; Mon, 14 Nov 2016 02:51:10 +0100 (CET) From: Brian Trammell X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_A77BB847-765A-40AA-9D09-074B35245473"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 14 Nov 2016 10:51:09 +0900 Message-Id: To: spud , stackevo-discuss@iab.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Spud] PLUS side meeting in Seoul, Tuesday 12:15 X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 01:51:18 -0000 --Apple-Mail=_A77BB847-765A-40AA-9D09-074B35245473 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, The PLUS proponents will have a design side meeting in the Park Studio = room on the 5th floor of the Conrad Seoul tomorrow, Tuesday 15 November, = at 12:30. The purpose of this meeting will be to decide what would need = to be done before a second attempt at a working group forming BoF, and = to find volunteers to help working on the drafts necessary. So, if = you're interested in PLUS and want to help, please come by. If you're coming to the meeting, please let us know, as space is quite = limited in the room (about 20). Also, make sure you get something to eat = beforehand (or on the way there), as there will be no lunch served. If you're interested in helping but are not free at lunchtime tomorrow, = please let us know that too. There are three (new) related drafts, now: (1) https://tools.ietf.org/html/draft-hardie-path-signals describes the = type of signaling inferable from current transport protocols, which PLUS = aims to replace in a transport-independent way; it's derived from Ted's = talk at the PLUS BoF in Berlin. (2) https://tools.ietf.org/html/draft-trammell-plus-abstract-mech is a = more-complete description of the abstract mechanisms for signaling = described in my slides in the PLUS BoF in Berlin. (3) https://tools.ietf.org/html/draft-trammell-plus-statefulness defines = a minimal transport-independent state machine for state-keeping = middleboxes and a set of abstract signals for driving this state = machine, to replace the path signaling in (1). We do have a rough sketch of the way forward: (1) We have tightened the scope of the proposal (see the current = proposed charter at = https://github.com/ietf-plus/charter/blob/master/charter-plus.txt), = restricting it to replacing those path signals that are commonly assumed = to be available for on-path state management (as discussed in = draft-hardie-path-signals), implementing the mechanism described in = draft-trammell-plus-statefulness. (2) We would like to attempt to have another BoF, but not without having = a protocol document, defining a protocol which solves the more = restricted state signaling problem. The discussion will go much more = smoothly with bits on the wire to argue about. This protocol will be = largely based on the statefulness draft, above, while the abstract = mechanisms in draft-trammell-plus-abstract-mech would be used for = timeout discovery and exposure. (3) We have requested a plus@ietf.org mailing list; this is in = processing and should happen soon. We'll announce here when it does. We = should have done this before the PLUS BoF in Berlin, actually. After = this move, the SPUD list will be closed (as that experiment has = completed); please subscribe to plus@ietf.org once it's up if you're = interested in following the PLUS effort. Cheers, Brian and Mirja --Apple-Mail=_A77BB847-765A-40AA-9D09-074B35245473 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYKRiNAAoJEIoSt78L6kajY4MQAMOlqr2CVnxB28F/BiWhHPgQ VC/s8uN1QTO2FtTy/8/VIq8vVp3A+JMqH/WtYsPzfDY8vyRVt+OxRpmcvuMZ01oz p3lEi+fQ7ibfx3Ul2VGKO4ODHnph9VLJQImCwul9cGHq7IkTas0Ag/cLrRIDlcax a+LvUC+fkH0+d0E7psmFv9nWMwtMCeNOz2PE3rAG8R4PK5gVSmHY/dG3848uiHHV HKUPgZgEpnfkMG3eOU+XKwUoiWXfr2jn9fMZXLnAay+7iCjJ4Wv66/Y/kCVNaCgv ixKON2HQiBzDVsHLfCmYiu6s2rh0hPislL/R7MQuEdT1qPHqyFSZj25sIOhBNIVi 6lmmqxk7FbuD6W8qykY+PCwIh1NbjE/XdJ2+ynxH5vKAR4Fpy56mkqlP6IMOu5ER 0b9f3LPPgEwNjb6I0lFAg1MdPvaUVq3yN8of9Nsja7NPA8ov42j+IDacNtn6MHqr 9/NnNgKHexj8kk5fTIJ7Kn3+1SmMuxtjwziCg3Xx4S9Q3IqWDKohiYhQwT0rN0Ic lqtO1vEqEkG6403yey4bZYJ/YeBoSyXtRFuACh4rFRyCVf6JPcCgvCf66ssjbb8A aUzCfpugF9ZQFkoEjNHwAy/t0iUL+Y7dDOr3jzL9uf38ZffxruOzfB6OrSIiTZNo JGSTV6ZJSqEZW9byDnLJ =DTrb -----END PGP SIGNATURE----- --Apple-Mail=_A77BB847-765A-40AA-9D09-074B35245473-- From nobody Sun Nov 13 17:56:21 2016 Return-Path: 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 2C21F1293EE for ; Sun, 13 Nov 2016 17:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 3WV28mRSbtWu for ; Sun, 13 Nov 2016 17:56:18 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1537E1295F2 for ; Sun, 13 Nov 2016 17:56:18 -0800 (PST) Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id BB5701A06A1; Mon, 14 Nov 2016 02:55:45 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A1A4F83A-4318-4C5F-9888-E3377D29137A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Mon, 14 Nov 2016 10:55:42 +0900 Message-Id: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> References: To: Dave Dolson X-Mailer: Apple Mail (2.3124) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 01:56:20 -0000 --Apple-Mail=_A1A4F83A-4318-4C5F-9888-E3377D29137A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Dave, Thanks for the feedback! Responses inline... > On 11 Nov 2016, at 19:55, Dave Dolson wrote: >=20 > Mirja, Brian, Joe, >=20 > I think it is an interesting idea to formalize/standardize the state = machine that should be used by flow-stateful network equipment. >=20 > But having read about the four states and three timeouts, I feel you = are missing a state after biflow that represents a fully proven = connection. >=20 > I=E2=80=99m thinking of the problem of source-spoofed SYN attack = packets that attempt to consume state memory in servers and = flow-stateful network devices. > A network device may see client SYN and server SYN-ACK but never the = completed 3-way handshake because the client is not real. >=20 > Until the 3-way handshake is completed, only short timeouts should be = used. This is true for server as well as stateful network devices. The 3-way handshake is TCP-specific; other protocols will have different = patterns. However, to generalize, it may make sense to require a two-way = association signal before entering the biflow state, i.e. [zero] --packet fwd--> [uniflow] --association rev--> [associating] = --association fwd--> [biflow] with the timeout remaining t1 for the associating state. > The nice thing about the client=E2=80=99s ACK of the server=E2=80=99s = SYN flag is that it echoes back (in the ACK field) the SYN sequence = number, which is unlikely to be guessed by an attacking node that = doesn=E2=80=99t own the address it used in the SYN packet. The ACK = packet also carries the original client sequence# + 1, proving it has a = stateful connection. >=20 > As an alternative to adding a state, you could enter the bi-flow state = only when the TCP 3-way handshake is complete. We'd need an additional state to do this anyway, as above. >=20 > Does QUIC carry a network-observable signal indicating receipt of the = server packet? 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-signa= ling-and-quic-00.pdf Cheers, Brian --Apple-Mail=_A1A4F83A-4318-4C5F-9888-E3377D29137A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYKRmeAAoJEIoSt78L6kajK70QALBmOjLl3HsrKiv2Y9jJhY9t vynwKJFACuSQE6kYkpP1OOMoZtkSXVxZIAFPxudcVY5zXI82D4YZwQeCx1NZEnw0 s+8EhBrn8gu9ZLyh22w8qb6Y6kQOQKElD1KE3DSo5WaMjoBHncPU35TtMwFOc+TB uZ2DnOkVOIc4HVCuU98+Yh6L1bGTv6gcwiMzWiYoC5vke+pn2TViG922d54B+INY jXDldCiOT8/zQoI1Fq6EOqb1muP6YRNzHxdnN2FTZPZ3lNiS5/AngyjezSSWX8PE HYv7Mh9g5/vvau18+IK8YC2xzPouI2tyaPsyIhkUYb7q4ecrp8gmVxrafAjhlj5+ ssDPv6HuOsvMhzBSOr6FXdrLZO3bubcjFC4UmFdFzTk6ZzQxDz0KErVCJkDrbQA6 iNteZjxYzp9pagNYr6Bm1e617T+uJifXtMBSWPbVFcTIwoHOdM/ulMCvery1P2bC tOGYNCyAV9ak0ycbGmDvBIGbYYXN5e84gnX8PsNvCgHeOPJPtHo/J6deMr479L/1 P476plZ3XNgnh1ZS8WIP8+INzYXQ02fitu6uiTpoP6ye8eKEpJEZ+HbQJ8zAAMHU a5l6lmzwMC9MjcmBAr4twgluJzwXl+G3eMBs0U2/Cf4khmf/tEZwlCYCaLwXb8rC lMDWlfmx8Bk3g9sV1/qA =uFqZ -----END PGP SIGNATURE----- --Apple-Mail=_A1A4F83A-4318-4C5F-9888-E3377D29137A-- From nobody Mon Nov 14 09:27:53 2016 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 ) 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 ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Nov 2016 17:21:09 -0000 From: "Christian Huitema" To: "'Brian Trammell'" , "'Dave Dolson'" References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=20 > = https://www.ietf.org/proceedings/97/slides/slides-97-quic-flow-state-sign= aling-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."=20 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.=20 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=3D =3DcZq+ -----END PGP SIGNATURE----- From nobody Mon Nov 14 09:58:32 2016 Return-Path: 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 805851294BA for ; Mon, 14 Nov 2016 09:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 j8teALqINuRn for ; Mon, 14 Nov 2016 09:58:30 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24F11294CE for ; Mon, 14 Nov 2016 09:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2962; q=dns/txt; s=iport; t=1479146310; x=1480355910; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=pqGrj2SxxRy1uwNql+IT0wxp48Py9OAMj9FsHqJkCZA=; b=cL8L0R2itnHvo8Jbb4RjvpoYWSLgWjBUFkyo8lCq1zb4lh9YoEpEX26A O8CfQc1tzBo8f/mvWjmcDI5CO2kp6g+zeoCGPALkkw6h409GbYgrKFXPU tXcdz2kOFv7uHtighzxAr4jiv/ASbtal2yiZPjH1tOoldTMvh2oWshOna g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APBQBj+ilY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzEBAQEBAYEjpRyWZ4YjAoJlEAECAQEBAQEBAWIohGEBAQEDASN?= =?us-ascii?q?WBQsLGCoCAlcGAQwIAQGIVQivToIpi04BAQEBAQEBAQEBAQEBAQEBAQERDog5g?= =?us-ascii?q?l2HTIJdBZpBg1GBeocIhAqCBod5hiGRTjUgZxELhTc9iDABAQE?= X-IronPort-AV: E=Sophos;i="5.31,491,1473120000"; d="asc'?scan'208";a="649934899" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2016 17:58:28 +0000 Received: from [10.61.195.208] ([10.61.195.208]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAEHwR8u011407; Mon, 14 Nov 2016 17:58:27 GMT To: Christian Huitema , "'Brian Trammell'" , "'Dave Dolson'" References: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> From: Eliot Lear Message-ID: Date: Mon, 14 Nov 2016 18:58:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <03b101d23e9b$7c883540$75989fc0$@huitema.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="up46ssM1hSSrkv1MvLSAkRDsrfwwBd6Xh" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 17:58:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --up46ssM1hSSrkv1MvLSAkRDsrfwwBd6Xh Content-Type: multipart/mixed; boundary="egiswvrmCSVwCrFB5JAgPvkhDleDud9NF"; protected-headers="v1" From: Eliot Lear To: Christian Huitema , 'Brian Trammell' , 'Dave Dolson' Cc: hildjj@cursive.net, mirja.kuehlewind@tik.ee.ethz.ch, spud@ietf.org Message-ID: Subject: Re: [Spud] States in draft-trammell-plus-statefulness-00 References: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> In-Reply-To: <03b101d23e9b$7c883540$75989fc0$@huitema.net> --egiswvrmCSVwCrFB5JAgPvkhDleDud9NF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christian, On 11/14/16 6:21 PM, Christian Huitema wrote: > On the other hand, since endpoints may well just drop off a route > without notice, we know that timers are needed in any case.=20 Yes, needing them and waiting for them to fire off are two different things, right? It's better to have a mechanism that cleans up sooner than later. If we have that mechanism then we use fewer resources (memory) per flow on average and that in turn means supporting more flows= =2E.. > So, we could frame the problem simply as "can we find an alternative > to timers for state management." > Yes. > 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 nice thing about TCP being stateful, however, is that the middlebox has reason to trust how an end device is going to handle something that is outside the state machine. It's really well defined. That's the good part. The bad part is that then the state machine is ossified. Eliot --egiswvrmCSVwCrFB5JAgPvkhDleDud9NF-- --up46ssM1hSSrkv1MvLSAkRDsrfwwBd6Xh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYKftCAAoJEIe2a0bZ0nozPvoH/1XThwSt8ruQmAlOhcR25Bn9 W0QV3e/vWa4D/vDfvT2ME/FC/9w2Z2ilHilRpPzgfaesYn/SiZ9wEBXO2wREWMeq eF3TEJYWRnNcaaf4bZ96oYv6m/zkN/TMnPP4k7c2uqAWiIVEJcI5EZV3VUMjPL+E dBvJ6QTDe/HZfz5iTBoDaSNTjEnLEAZdrTQLNWn0knvSd3kV6H5CPhe981YNbo4/ 2hadyvW09lCgasyATar2irBF0uCvptH/zrHkuxTmFS5mwd8fyQlN1Szxv//Pl+eR s16lMjSyKpCnvE1vg6/TiG3bndqzIwNwafTWyF7DVPkOA3kictBO4BOu0f32i4c= =35KX -----END PGP SIGNATURE----- --up46ssM1hSSrkv1MvLSAkRDsrfwwBd6Xh-- From nobody Mon Nov 14 10:18:49 2016 Return-Path: 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 BAAC41294A0 for ; Mon, 14 Nov 2016 10:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 kVDMOHqz4cKC for ; Mon, 14 Nov 2016 10:18:44 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 34A78129409 for ; Mon, 14 Nov 2016 10:18:44 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 28F4CB49391A5; Mon, 14 Nov 2016 18:18:39 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAEIIf9K001838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2016 18:18:41 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uAEIHVsR007011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Nov 2016 19:18:40 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.241]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Mon, 14 Nov 2016 19:18:15 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Christian Huitema , "'Brian Trammell'" , "'Dave Dolson'" Thread-Topic: [ALU] Re: [Spud] States in draft-trammell-plus-statefulness-00 Thread-Index: AdI7o1fE+iaNGCadS5OC9ubAYOjCyQCbnsUAACBRkoAAAf2fgA== Date: Mon, 14 Nov 2016 18:18:14 +0000 Message-ID: References: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> In-Reply-To: <03b101d23e9b$7c883540$75989fc0$@huitema.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <4FE35DF94867FF44BBF58FA7C0DF5625@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "hildjj@cursive.net" , "mirja.kuehlewind@tik.ee.ethz.ch" , "spud@ietf.org" Subject: Re: [Spud] [ALU] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 18:18:46 -0000 On 14/11/2016 17:21, "Spud on behalf of Christian Huitema" wrote: >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, Premise: I agree that PLUS should be properly separated from QUIC. I am concerned that making QUIC (standard) depend on PLUS (experimental) for this pretty essential function can be tricky. How do you think this should be handled? From nobody Mon Nov 14 11:01:38 2016 Return-Path: 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 2078C1299A6 for ; Mon, 14 Nov 2016 11:01:37 -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=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 SJfzIhJC2dgr for ; Mon, 14 Nov 2016 11:01:35 -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 6E01F1299A4 for ; Mon, 14 Nov 2016 11:01:35 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1c6MVW-0000p5-3K for spud@ietf.org; Mon, 14 Nov 2016 20:01:34 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1c6MV0-0006HM-EJ for spud@ietf.org; Mon, 14 Nov 2016 14:01:29 -0500 Received: (qmail 22771 invoked from network); 14 Nov 2016 18:56:14 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[208.54.39.200]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Nov 2016 18:56:13 -0000 From: "Christian Huitema" To: "'Eliot Lear'" , "'Brian Trammell'" , "'Dave Dolson'" References: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> In-Reply-To: Date: Mon, 14 Nov 2016 10:56:10 -0800 Message-ID: <013401d23ea8$c4d113f0$4e733bd0$@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+wBtT6LQEXHGdBAvEncUwB9gfkzp8NdbZQ Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dNEAmMBmHDUmmY+3eqwn6k80HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD6v+ Tgijk3LAC5JznZJ001wGCGSYTechvslUb/W6HSHodcmtTcWSOKD5RASVzg27isfnUU8Aq9Xij6e6 U5pAs/95kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbd0npwMH44Pt2njKMwCMVe5fi885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokuKS3SvBae3MYJkcyURBnFAZIe8Pggnek1xH/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.230 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.31) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 19:01:37 -0000 On Monday, November 14, 2016 9:58 AM, Eliot Lear wrote: > The nice thing about TCP being stateful, however, is that the = middlebox > has reason to trust how an end device is going to handle something = that > is outside the state machine. It's really well defined. That's the > good part. The bad part is that then the state machine is ossified. That's not the only bad part. Looking for SYN/SYN-ACK won't work if = packets follow a new path after a route change, as could easily happen = with multi-homing.=20 Also, the lack of authentication allows for the "spoofed RST" attack, in = which injecting a single packet can cause connections to be dropped. = That's why I would rather see mechanisms in which the magic packets have = to flow in both directions. For example, a middlebox sees "drop me" = coming from the left, and simply marks the state as "drop from left = requested". If it receives a corresponding "drop me" from the right, the = state is dropped. If on the contrary it receives a regular packet from = the left, then it suspects spoofing and the state reverts to normal. -- Christian Huitema From nobody Mon Nov 14 11:01:52 2016 Return-Path: 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 E73531299AA for ; Mon, 14 Nov 2016 11:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 nB0aEussigJY for ; Mon, 14 Nov 2016 11:01:42 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 E1B941299A9 for ; Mon, 14 Nov 2016 11:01:41 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1c6MVF-0002sS-99 for spud@ietf.org; Mon, 14 Nov 2016 20:01:32 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1c6MV7-0003wh-86 for spud@ietf.org; Mon, 14 Nov 2016 14:01:05 -0500 Received: (qmail 25420 invoked from network); 14 Nov 2016 19:01:04 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[208.54.39.200]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Nov 2016 19:01:04 -0000 From: "Christian Huitema" To: "'Fossati, Thomas \(Nokia - GB\)'" , "'Brian Trammell'" , "'Dave Dolson'" References: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> In-Reply-To: Date: Mon, 14 Nov 2016 11:01:00 -0800 Message-ID: <013701d23ea9$71f87870$55e96950$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKf862m8oZQa9APzsImua+wBtT6LQEXHGdBAvEncUwBgY7ctZ8RG9Ng Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dNEAmMBmHDUmmY+3eqwn6k80HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD/Sl +YPTcpciItwmJjf3RtnaS++bgimGC/mr3XgFs+3cdcmtTcWSOKD5RASVzg27in97Vz6IRLbhBYyX 7lr6B6d5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdbNYJZHmTztvoh1m9SAwL4/i885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokd0uMbDf1yoqZkUeJni0+RQZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVJ52x4j7SJ9+yFYhxTTZdKAmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV46n/TYyQX4QewGgUaWBSqGlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.234 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.15) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: hildjj@cursive.net, mirja.kuehlewind@tik.ee.ethz.ch, spud@ietf.org Subject: Re: [Spud] [ALU] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 19:01:51 -0000 On Monday, November 14, 2016 10:18 AM, Fossati, Thomas (Nokia - GB) wrote: > Premise: I agree that PLUS should be properly separated from QUIC. > > I am concerned that making QUIC (standard) depend on PLUS (experimental) > for this pretty essential function can be tricky. > > How do you think this should be handled? Realistically, although I don't like it, I assume that middleboxes will just start inspecting packets and recognizing QUIC. On the other hand, QUIC specifies an "abrupt disconnect" packet that looks pretty much like what we would want a "drop me" packet to do. Aligning PLUS with that one way or another could be helpful. -- Christian Huitema From nobody Mon Nov 14 18:57:08 2016 Return-Path: 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 0C4DE1299B6 for ; Mon, 14 Nov 2016 18:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 n1vCzb8spn3D for ; Mon, 14 Nov 2016 18:57:06 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 202F712968C for ; Mon, 14 Nov 2016 18:57:06 -0800 (PST) Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id 22B581A05C6; Tue, 15 Nov 2016 03:57:02 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6396A05C-0049-4B03-8E61-842679816711"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <013401d23ea8$c4d113f0$4e733bd0$@huitema.net> Date: Tue, 15 Nov 2016 11:56:57 +0900 Message-Id: References: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> <013401d23ea8$c4d113f0$4e733bd0$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hildjj@cursive.net, mirja.kuehlewind@tik.ee.ethz.ch, Dave Dolson , Eliot Lear , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:57:08 -0000 --Apple-Mail=_6396A05C-0049-4B03-8E61-842679816711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Christian, Eliot, all, We really need to go off and define a plus-protocol document that shows = bits on the wire, so we can have this discussion with something more = concrete to point at. (We'll be putting together an design and editorial = team for that at the aforementioned side meeting today, and expect a = first strawman -00 before the end of the year.) But in the meantime... > On 15 Nov 2016, at 03:56, Christian Huitema = wrote: >=20 > On Monday, November 14, 2016 9:58 AM, Eliot Lear wrote: >> The nice thing about TCP being stateful, however, is that the = middlebox >> has reason to trust how an end device is going to handle something = that >> is outside the state machine. It's really well defined. That's the >> good part. I'll take the opposite side of this argument, with respect to the state = machine in -statefulness: The signals in this state machine are *explicitly* only for the usage of = the path. The association signals are exposed when the overlying = transport decides they should be. >> The bad part is that then the state machine is ossified. >=20 > That's not the only bad part. Looking for SYN/SYN-ACK won't work if = packets follow a new path after a route change, as could easily happen = with multi-homing. This state machine will continue to work as long as *every* packet, not = just "first packets", carries enough information to extract an = association signal. > Also, the lack of authentication allows for the "spoofed RST" attack, = in which injecting a single packet can cause connections to be dropped. If the for-the-path stop signal is (1) integrity protected at the = endpoints and (2) carries enough information to be non-spoofable (as in = TCP, RSTs must be in-window, giving you 16ish bits of off-path guess = protection; we'd want at least 32 bits), then off-path attacks are = unlikely. The for-the-path stop signal is separate in this case from the = (confidentiality and integrity protected) connection stop signal. = On-path attacks remain, as with TCP, possible. But if every packet = contains enough information to extract an association signal, the = on-path state will simply cycle through closing-zero-uniflow and return = to biflow. How much state is lost and has to be re-established here is a different, = and application-specific, question. Cheers, Brian > That's why I would rather see mechanisms in which the magic packets = have to flow in both directions. For example, a middlebox sees "drop me" = coming from the left, and simply marks the state as "drop from left = requested". If it receives a corresponding "drop me" from the right, the = state is dropped. If on the contrary it receives a regular packet from = the left, then it suspects spoofing and the state reverts to normal. >=20 > -- Christian Huitema >=20 >=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_6396A05C-0049-4B03-8E61-842679816711 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYKnl5AAoJEIoSt78L6kajlRoP/3yX9NcBE8+537fp1quLZv+r hnsxrF+MdM2K1YLpls11NpRgmhFAl6d1jZrOJj5oCic4FdsLAnT5jSkRqU0DaQpU La9NJUZDrVdnaJnoKf8INNFocGD5tIiXlpSkTeUo+m3SnXaSBUfn124Wj/4sanlD +5D01Gj9MfQ8KwqVwHelx0jqLKopf7jXfijWs+OCBVML9HU3tzQlfMmA3yzvWWY0 KHI6V087CE+dBQE0eFK2w4InKkK8jfnfBbY3AJGdDSSNbZhLlT//vrx93EUB2GWx TFwjXDAO1XfymCWePc4B2/dqHrLyIzXltbRgjeuYFTtXhJoNGmvuRZWYFsaNjFf2 PgGdAxqMH/4nPChb9kJVIv14V6e3IGr/oW82Ep47ssUMJq9dyn9krlnt8hUHb3Pi BVXW3v9A82oznpZMnbR0w9+WDQHctpCeqTpzddS2kQhrpa1gQalUDB+6xLRrU41S v219XpFEswaY6jxU1W3mLbxoK4ynUBE+yL1tUOpklSSEFQiI4TifqotHQ1wxUfpS t/1zWYFzf0xkqYbmmXm3e8+8NjffGf15HXE59PjOoN2654L2uHQOl1iLtTK6DhrU 1rviiunmdsIDpJhPWGVAl8xMbFxrjxb2sSg0MSi5y1/b0mPZtYQ6c9LD41lVm60D 14fvHZ2sq+l/xr7fBJib =4tgV -----END PGP SIGNATURE----- --Apple-Mail=_6396A05C-0049-4B03-8E61-842679816711-- From nobody Mon Nov 14 19:10:59 2016 Return-Path: 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 7EA8E129A0D for ; Mon, 14 Nov 2016 19:10:58 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 9sBJEzSNNPsR for ; Mon, 14 Nov 2016 19:10:53 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380A8129A0B for ; Mon, 14 Nov 2016 19:10:53 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n204so120707109qke.2 for ; Mon, 14 Nov 2016 19:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eB0qdC45uezWI2+MbvAwutVrJagGLs2J/G78sBBA/3Q=; b=qHTQvabyja3UHl4EEQEya+7BYPt4A/OWXlqPEVnloqqvbS6PG/YqPwkcyIBCRQ/hOm 8Kc7vHgkWfmD5ix8UEgaT5H5yS03sDsKZFnI/75GvXmMXVRN0+0FgOIAgkr+/B3F/Ebn y0sfelbdl3h2RNSccjxUqW0q9qCYckpH9+Ei3cszFM0qhj9UFglf3iBcug/48j3mMmFC vK0qWij2P8ZLYfcFFcUII1emCiyDe3nmIzoCHRwRweKPULyCk3VkkGCcflbjNojYpv+X kp79WEPomX3qtbBm/xLkpUpjlK+KVEryxaq5C+ksvDukS5jhJXo0uMaygARhjL3xxjS3 7L/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eB0qdC45uezWI2+MbvAwutVrJagGLs2J/G78sBBA/3Q=; b=i0O32k3V3lVXyxsHX374Bru8UVBLt6PNCTmtG1axQ940hdrmNksR5pDlVWK0ClQqFe FrBfB9Tuyt+qFEdGImUBwBYgyiwrXdCGLqKz9ZG6dBjGmHjw+wcrcjprKEc3iW0TUoJC B1r1nJR6umnA1z7Sfn0Y/4xF/dtndeMZVtaKf9wIplZV8bj6tdUHdnh+OZwV5YPa193m POK2SDADtc46EH+QweMLDr/hWcSv2yq/+iLlE9qTYGsvK/ar+1MvLFW5n/nYPaBGKPEl BqfoEHGq6dUeaLS/Tsk9tUlgJQrVNbm27FpfLr4M0YSzJ+mnVsGZb8+7U56PiK7sdL4a 7Mng== X-Gm-Message-State: ABUngveQlm2Shoiw+AJbapZkb+YVyaTR9rA3St/uEZmPf6TYMt7pfR3F0QKCdKgn6jonH87UQxeyzzBcG7nBOg== X-Received: by 10.55.41.39 with SMTP id p39mr20497908qkh.245.1479179452343; Mon, 14 Nov 2016 19:10:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.58.197 with HTTP; Mon, 14 Nov 2016 19:10:51 -0800 (PST) In-Reply-To: <013401d23ea8$c4d113f0$4e733bd0$@huitema.net> References: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> <013401d23ea8$c4d113f0$4e733bd0$@huitema.net> From: Tom Herbert Date: Tue, 15 Nov 2016 12:10:51 +0900 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a1147b374d11b3405414e4d80 Archived-At: Cc: hildjj@cursive.net, Eliot Lear , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud , Brian Trammell , Dave Dolson 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 03:10:58 -0000 --001a1147b374d11b3405414e4d80 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 15, 2016 at 3:56 AM, Christian Huitema wrote: > On Monday, November 14, 2016 9:58 AM, Eliot Lear wrote: > > The nice thing about TCP being stateful, however, is that the middlebox > > has reason to trust how an end device is going to handle something that > > is outside the state machine. It's really well defined. That's the > > good part. The bad part is that then the state machine is ossified. > > That's not the only bad part. Looking for SYN/SYN-ACK won't work if > packets follow a new path after a route change, as could easily happen with > multi-homing. > > Networking maintaining state and multihoming was raised as a concern in the BOF in Berlin. Has there been any work on how to resolve that in PLUS? Thanks, Tom Also, the lack of authentication allows for the "spoofed RST" attack, in > which injecting a single packet can cause connections to be dropped. That's > why I would rather see mechanisms in which the magic packets have to flow > in both directions. For example, a middlebox sees "drop me" coming from the > left, and simply marks the state as "drop from left requested". If it > receives a corresponding "drop me" from the right, the state is dropped. If > on the contrary it receives a regular packet from the left, then it > suspects spoofing and the state reverts to normal. > > -- Christian Huitema > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --001a1147b374d11b3405414e4d80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 15, 2016 at 3:56 AM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
On Monday= , November 14, 2016 9:58 AM, Eliot Lear wrote:
> The nice thing about TCP being stateful, however, is that the middlebo= x
> has reason to trust how an end device is going to handle something tha= t
> is outside the state machine.=C2=A0 It's really well defined.=C2= =A0 That's the
> good part.=C2=A0 The bad part is that then the state machine is ossifi= ed.

That's not the only bad part. Looking for SYN/SYN-ACK won't = work if packets follow a new path after a route change, as could easily hap= pen with multi-homing.

Networking maintaining state and multihoming was rais= ed as a concern in the BOF in Berlin. Has there been any work on how to res= olve that in PLUS?

Thanks,
Tom

Also, the lack of authentication allows for the "spoofed RST" att= ack, in which injecting a single packet can cause connections to be dropped= . That's why I would rather see mechanisms in which the magic packets h= ave to flow in both directions. For example, a middlebox sees "drop me= " coming from the left, and simply marks the state as "drop from = left requested". If it receives a corresponding "drop me" fr= om the right, the state is dropped. If on the contrary it receives a regula= r packet from the left, then it suspects spoofing and the state reverts to = normal.

-- Christian Huitema



_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud

--001a1147b374d11b3405414e4d80-- From nobody Mon Nov 14 21:08:02 2016 Return-Path: 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 2B0BB129473 for ; Mon, 14 Nov 2016 21:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 xaJXRcTIHBvp for ; Mon, 14 Nov 2016 21:07:58 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4908B129A0E for ; Mon, 14 Nov 2016 21:07:50 -0800 (PST) Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id D6D851A1052; Tue, 15 Nov 2016 06:07:16 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1A6D4A49-009B-4EA6-8794-4C5219D6BE3D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Tue, 15 Nov 2016 14:07:13 +0900 Message-Id: <52FC4F6A-73DF-436B-8A91-ADBA1A911DC6@trammell.ch> References: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> <013401d23ea8$c4d113f0$4e733bd0$@huitema.net> To: Tom Herbert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hildjj@cursive.net, Eliot Lear , Christian Huitema , spud , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Dave Dolson 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 05:08:01 -0000 --Apple-Mail=_1A6D4A49-009B-4EA6-8794-4C5219D6BE3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Tom, > On 15 Nov 2016, at 12:10, Tom Herbert wrote: >=20 >=20 >=20 > On Tue, Nov 15, 2016 at 3:56 AM, Christian Huitema = wrote: > On Monday, November 14, 2016 9:58 AM, Eliot Lear wrote: > > The nice thing about TCP being stateful, however, is that the = middlebox > > has reason to trust how an end device is going to handle something = that > > is outside the state machine. It's really well defined. That's the > > good part. The bad part is that then the state machine is ossified. >=20 > That's not the only bad part. Looking for SYN/SYN-ACK won't work if = packets follow a new path after a route change, as could easily happen = with multi-homing. >=20 > Networking maintaining state and multihoming was raised as a concern = in the BOF in Berlin. Has there been any work on how to resolve that in = PLUS? The current scope reduced to focusing on how to maintain state and the = state machine defined in draft-trammell-plus-statefulness. This state = machine, when driven by association signals derivable from each packet, = will resynchronize state when a route changes on a multihomed network. = (For multipath protocols, the transport association is made up of = multiple flows, and the state is maintained on a per-flow basis). Cheers, Brian > Thanks, > Tom >=20 > Also, the lack of authentication allows for the "spoofed RST" attack, = in which injecting a single packet can cause connections to be dropped. = That's why I would rather see mechanisms in which the magic packets have = to flow in both directions. For example, a middlebox sees "drop me" = coming from the left, and simply marks the state as "drop from left = requested". If it receives a corresponding "drop me" from the right, the = state is dropped. If on the contrary it receives a regular packet from = the left, then it suspects spoofing and the state reverts to normal. >=20 > -- Christian Huitema >=20 >=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud >=20 --Apple-Mail=_1A6D4A49-009B-4EA6-8794-4C5219D6BE3D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYKpgBAAoJEIoSt78L6kajDBEP/ArE0uYpWy/8L7OGY87B+dhO oYhfvB2sIKrF7g7RvCIPM1jiVwO5DzQ3B5VA4hFLXhCmjZo3uoud/ewisj/H9dYW p8sxvYndFBitdVuuhKYhw/fludHKPfpnYoLRob4UmqEUhWd2qefVMW6veKayAEdD ridCvQR8JpgszbLa1zJ5aM/MnC6s2Z3Rv3m0aeKGMJ9tXajdmDNKgx3hs9gsxFk6 MfhEhkatbHpbdxHHVF7fZ6M9P2AjkUoJSQuYGTwJYD4tJJ5lA5IU/qDJb4pBGeFc N0XTw8Wmbio45zfukzTRaSTXV6d9NV39m9wW0Bxcp1T6Y/6i6pBUOhkd3xmoByXM 4MGk0SOcn3ZQPeARv/hkJ0nsa57z+7otFL9DA8B8ywlupy5WLDNZnBpEu8uySTsu ZuP0mvatsUkvqsxw7lRCM0nxmpkKbEFDuTv9xOGc6+SruNCnYX5GI2cTnDSNfGgn mNhTmc+xMxUQ3M5Tz1PYOckYJyZBCC/VFmQaGzX6mO7o34VqXVrKjtAc6jPkCMI+ 25bMD5HOBujHGgDGoRHaoYFAdImXofQ7lTLQUMtuVzQ4bdTZ1UYOy+eKew7LhpAN DeNZBn5cGhkcYNWX5YltSgabXoZr9WuNdYuSYoTn3tW+kaQu8de/2g4gM8Duvp+v pLPu/7xOmKx8A0V/+7KG =lUOc -----END PGP SIGNATURE----- --Apple-Mail=_1A6D4A49-009B-4EA6-8794-4C5219D6BE3D--