From nobody Thu Apr 2 12:12:04 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD901B2D7E for ; Thu, 2 Apr 2015 12:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.111 X-Spam-Level: X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1aLBwxDefIGH for ; Thu, 2 Apr 2015 12:12:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB4B1B2D86 for ; Thu, 2 Apr 2015 12:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=294; q=dns/txt; s=iport; t=1428001922; x=1429211522; h=date:from:to:subject:message-id:mime-version; bh=pujQ2CbMM1EZW3Nz/aLefDghE17BBKwpyoVm9IgRjo8=; b=BGpotcTQyZjx5PGu9hTTOqwcx5RTk/53oMiQNJlElv/jW1q4ij3aRwCr g3GPVJZ4DMUZhWBOrX0CD0DWLdSoY/V16Y0Rt7VSeJrfat2KjaAiaEamj FolPzyPbVcPg4DhUgEZwIfdvUWxwa69uWDuciiHXb0W3puGKkEZrnhglm k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AqBQBKkx1V/4QNJK1cgwhSxkOFL4IbTAEBAQEBAX6EX3s0BXSIFw2mH6d1IJA/hBcFiyKJPYYKAYFXknEihA8egnQBAQE X-IronPort-AV: E=Sophos;i="5.11,512,1422921600"; d="scan'208";a="409135642" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 02 Apr 2015 19:12:01 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t32JC01d023711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Apr 2015 19:12:01 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t32JC07O009223 for ; Thu, 2 Apr 2015 12:12:00 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t32JC0R7009222 for spud@ietf.org; Thu, 2 Apr 2015 12:12:00 -0700 Date: Thu, 2 Apr 2015 12:12:00 -0700 From: Toerless Eckert To: spud@ietf.org Message-ID: <20150402191200.GR24286@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Spud] Third party disclosure X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 19:12:03 -0000 Sorry, day too late... Some possible third party trademarks on the use of the term tubes wrt to the Internet in SPUD: http://thedailyshow.cc.com/videos/uo1ore/headlines---internet http://thedailyshow.cc.com/videos/sokn5t/party-pooper Apologies if these don't work outside the US ;-( From nobody Wed Apr 8 11:39:44 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E5E1A8F38 for ; Wed, 8 Apr 2015 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham 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 4kbaeUN5HJlr for ; Wed, 8 Apr 2015 11:39:41 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA01A92BC for ; Wed, 8 Apr 2015 11:39:31 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CA762F984 for ; Wed, 8 Apr 2015 14:39:28 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 03CB62023A; Wed, 8 Apr 2015 13:39:16 -0500 (CDT) From: Daniel Kahn Gillmor To: spud@ietf.org User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 08 Apr 2015 14:39:16 -0400 Message-ID: <87iod631nv.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:39:42 -0000 Hi folks-- Thanks to those who organized the SPUD BoF at IETF 92. Despite having some serious big-picture concerns about SPUD overall, I sympathize with the general goal of facilitating encrypting more traffic to protect the confidentiality, integrity and anonymity of Internet communications, so i appreciate the effort. I'll write up the big-picture concerns separately, but right now i plan to focus on some of the concrete details that i find unconvincing about the idea and the associated proposals. I'll try to keep each detail relatively succinct. This message is about the need for open/close in SPUD, which in the presentations i saw was frequently the first example brought out to explain what advantages SPUD can offer to existing on-path equipment. These signals don't seem to provide any useful advantages to me: Open is superfluous, and Close is unreliable. Open is superfluous ------------------- Given the existing 5-tuple, on-path equipment trivially knows when a flow starts already: it is a 5-tuple that they haven't seen before. If you want to maintain a distinction between a one-side-opened flow and a replied flow, this is also traceable by looking at the 5-tuple. It's not clear that the "open" signal gives on-path equipment any additional useful information that it didn't have already from the 5-tuple. Close is unreliable ------------------- One of the reasons on-path equipment would like a "close" signal is so that they know when to tear down associations that are no longer needed. This would reduce memory consumption and make a device more resilient to DoS attacks that exhaust its connection table. Without "close", the on-path equipment has to rely on timers to decide when to tear down the connection. Unfortunately, we can't rely on endpoints to send Close. Legitimate endpoints crash, run out of power, or have their network connectivity cut. So on-path equipment needs to maintain timers anyway if they're tracking flow state instead of just passing IP traffic statelessly. And in a DoS scenario, it's trival for an actively malicious end-point to send lots of "open" messages without ever sending a "close", so it doesn't protect against DoS either. Why should SPUD bother with explicitly signalling open and close? --dkg From nobody Wed Apr 8 12:28:40 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896C41B355A for ; Wed, 8 Apr 2015 12:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 H0vOlbMigeYd for ; Wed, 8 Apr 2015 12:28:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3BA1B3553 for ; Wed, 8 Apr 2015 12:28:38 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (0.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (0.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.130.23; Wed, 8 Apr 2015 19:28:37 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([0.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([0.160.96.17]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 19:28:37 +0000 From: Christian Huitema To: Daniel Kahn Gillmor , "spud@ietf.org" Thread-Topic: [Spud] SPUD's open/close are unconvincing Thread-Index: AQHQcitjyluT4qW5rECm5Hf5sMmnv51DfByw Date: Wed, 8 Apr 2015 19:28:36 +0000 Message-ID: References: <87iod631nv.fsf@alice.fifthhorseman.net> In-Reply-To: <87iod631nv.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.254] authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(46102003)(2656002)(107886001)(66066001)(2501003)(99286002)(86362001)(106116001)(76576001)(54356999)(76176999)(50986999)(74316001)(92566002)(122556002)(2900100001)(102836002)(87936001)(40100003)(33656002)(77156002)(2950100001)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0540846A1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 19:28:36.9218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:28:39 -0000 > These signals don't seem to provide any useful advantages to me: Open is > superfluous, and Close is unreliable. Did you check the "reset middlebox attack" thread? It was threading much of= the same ground. The general notion is that passing session state informat= ion in a clear text header allows for a set of denial of service attacks "t= hrough the middleboxes." The simplest attack is a fake "stop" causing middl= eboxes to drop their state and thus terminate the session, even if end-to-e= nd authentication protects the end points against that attack. > Open is superfluous > ------------------- >=20 > Given the existing 5-tuple, on-path equipment trivially knows when a flow= starts > already: it is a 5-tuple that they haven't seen before. If you want to m= aintain a > distinction between a one-side-opened flow and a replied flow, this is al= so > traceable by looking at the 5-tuple. It's not clear that the "open" sign= al gives on- > path equipment any additional useful information that it didn't have alre= ady > from the 5-tuple. Yes. If it did, we would have to be concerned with route changes, which res= ult in the same five-tuple being routed through a new set of middleboxes. T= he route change would have to be signaled to the end point, so they repeat = the additional "open" information for the benefit of new middleboxes. That = looks like a big can of worms. > Close is unreliable > ------------------- >=20 > One of the reasons on-path equipment would like a "close" signal is so th= at they > know when to tear down associations that are no longer needed. > This would reduce memory consumption and make a device more resilient to > DoS attacks that exhaust its connection table. Without "close", the on-p= ath > equipment has to rely on timers to decide when to tear down the connectio= n. >=20 > Unfortunately, we can't rely on endpoints to send Close. Legitimate endp= oints > crash, run out of power, or have their network connectivity cut. So on-p= ath > equipment needs to maintain timers anyway if they're tracking flow state > instead of just passing IP traffic statelessly. And in a DoS scenario, i= t's trival for > an actively malicious end-point to send lots of "open" messages without e= ver > sending a "close", so it doesn't protect against DoS either. That, and the injection of fake stop packets by whoever can listen to the p= ath and inject from the side. > Why should SPUD bother with explicitly signalling open and close? Agree with you, it would be better if it just did not include these indicat= ions. The initial argument for open/close bit relates to "opening ports in the en= terprise firewall." That's probably better handled by an explicit signaling= protocol like the Port Control Protocol. In the previous thread, Tiru Redd= y pointed to the work in progress to add authentication to PCP, and to the = use of PCP to reduce the required frequency of keep alives. That seems more= robust than unauthenticated bits in a clear text header. -- Christian Huitema From nobody Wed Apr 8 12:39:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2990D1B3565 for ; Wed, 8 Apr 2015 12:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.511 X-Spam-Level: X-Spam-Status: No, score=-12.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 nBzYb6DA22nv for ; Wed, 8 Apr 2015 12:39:23 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B291B3554 for ; Wed, 8 Apr 2015 12:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3888; q=dns/txt; s=iport; t=1428521963; x=1429731563; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Q8KMUumxT3mHXK9QTOKSEo2fD7a5FbWKmEZGU2YnTs8=; b=Ru/2feDcbOav23ItCwQ23PUetZR63/2zLebgPmIl8ySMrqLZD17iG5Mt s/7uBuZGQICv3SJIuSpX/CmORG/n+eR5/l6WeFN41gWbiV8EOpbDheyuS sxUefhXwtoOUU8v79JyH0B0XfcS18KUHWe8bdI6KJWC5gmOkzldozJcGc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7BQCSgiVV/51dJa1cgwhSXMU9CoV9AoEsOxEBAQEBAQEBfYQgAQEEAQEBNzQLEAsYCSUPBRM2E4gqDcx5AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKLH+ELU8HgxeBFgWGHoUJj1MBgR2DN4JjiVqDSiKEDx4xgQIHgToBAQE X-IronPort-AV: E=Sophos;i="5.11,545,1422921600"; d="scan'208";a="139420109" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 08 Apr 2015 19:39:22 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t38JdLNr013340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 19:39:22 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t38JdL8p031658; Wed, 8 Apr 2015 12:39:21 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t38JdLP5031657; Wed, 8 Apr 2015 12:39:21 -0700 Date: Wed, 8 Apr 2015 12:39:21 -0700 From: Toerless Eckert To: Daniel Kahn Gillmor Message-ID: <20150408193920.GD24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87iod631nv.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:39:25 -0000 Daniel, a) I think one hope of SPUDs design is to make UDP look enough like TCP to persuade FWs (and similar middleboxes) to police / permit it as well as TCP flows are policed/permitted. b) If you don't like how it works, let me generalize the question, would like to hear your (and others) answers: What is the best possible design we can do to make UDP flows be equal or better permissible across WELL BEHAVED FW and similar middleboxes ? Please define "WELL BEHAVED"as part of your answer. c) If i read it correctly, SPUD can a) set up potentially multiple independent pipes across the same 5-tuple. b) A single pipe can go across different 5-tuples (multipath/mobility). These two features should explain why tracking 5-tuple as you suggest alone would not be sufficient. Btw: I am a fan of b), i don't think a) should be encouraged given experience with RTCweb. In that sense, the total number of pipes would even be equal or smaller than the number of 5 tuples. Cheers Toerless P.S.: Cool domain name. Is that indicative of the role you're planning to take in the discussion ? ;-))) (sorry, i can never resists these questions). On Wed, Apr 08, 2015 at 02:39:16PM -0400, Daniel Kahn Gillmor wrote: > Hi folks-- > > Thanks to those who organized the SPUD BoF at IETF 92. Despite having > some serious big-picture concerns about SPUD overall, I sympathize with > the general goal of facilitating encrypting more traffic to protect the > confidentiality, integrity and anonymity of Internet communications, so > i appreciate the effort. > > I'll write up the big-picture concerns separately, but right now i plan > to focus on some of the concrete details that i find unconvincing about > the idea and the associated proposals. I'll try to keep each detail > relatively succinct. > > This message is about the need for open/close in SPUD, which in the > presentations i saw was frequently the first example brought out to > explain what advantages SPUD can offer to existing on-path equipment. > > These signals don't seem to provide any useful advantages to me: Open is > superfluous, and Close is unreliable. > > Open is superfluous > ------------------- > > Given the existing 5-tuple, on-path equipment trivially knows when a > flow starts already: it is a 5-tuple that they haven't seen before. If > you want to maintain a distinction between a one-side-opened flow and a > replied flow, this is also traceable by looking at the 5-tuple. It's > not clear that the "open" signal gives on-path equipment any additional > useful information that it didn't have already from the 5-tuple. > > > Close is unreliable > ------------------- > > One of the reasons on-path equipment would like a "close" signal is so > that they know when to tear down associations that are no longer needed. > This would reduce memory consumption and make a device more resilient to > DoS attacks that exhaust its connection table. Without "close", the > on-path equipment has to rely on timers to decide when to tear down the > connection. > > Unfortunately, we can't rely on endpoints to send Close. Legitimate > endpoints crash, run out of power, or have their network connectivity > cut. So on-path equipment needs to maintain timers anyway if they're > tracking flow state instead of just passing IP traffic statelessly. And > in a DoS scenario, it's trival for an actively malicious end-point to > send lots of "open" messages without ever sending a "close", so it > doesn't protect against DoS either. > > > > Why should SPUD bother with explicitly signalling open and close? > > --dkg > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Wed Apr 8 13:53:28 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEFE1B365E for ; Wed, 8 Apr 2015 13:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 qks3_TKDEyXs for ; Wed, 8 Apr 2015 13:53:26 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7D31B362F for ; Wed, 8 Apr 2015 13:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2214; q=dns/txt; s=iport; t=1428526408; x=1429736008; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MEf1KCrDYvM69+9E+rP5ud39Agi0TeVtJ5wai0em8iQ=; b=KQIq/ALczlsOBKPx5Hz9LkKxbyxy96J1yUKbmLI480E3SoSwhNmH+zrR W6AiOUQUvVFPoCNAnofgCQyfHhDlfa2DxylsDEOSnIosA8MZ4unu9unjD TtzAEfAgXYFEhQLrvVgIhNbofa+q1ohrPrRD1In1zs+JuePPzU4Jq71nj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQAblCVV/4ENJK1cgwiBLgWDEL9xb4dPAhyBEjoSAQEBAQEBAX2EIAEBBCMRRRACAQgaAhEVAgICMBUQAgQBDQUbiA+2S5ZRAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhigqESTMHCoJeL4EWAQSQdIoHlFsig29vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,545,1422921600"; d="scan'208";a="139421062" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 08 Apr 2015 20:53:27 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t38KrPgE016597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 20:53:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 8 Apr 2015 15:53:25 -0500 From: "Joe Hildebrand (jhildebr)" To: "Toerless Eckert (eckert)" , Daniel Kahn Gillmor Thread-Topic: [Spud] SPUD's open/close are unconvincing Thread-Index: AQHQcitjI1D3RHk2H0SfkwcdNYTIfZ1D1uaA//+wGwA= Date: Wed, 8 Apr 2015 20:53:24 +0000 Message-ID: <09D0D481-9380-42CA-94B1-895EC9E51428@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> In-Reply-To: <20150408193920.GD24286@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.2.150328 x-originating-ip: [10.129.24.173] Content-Type: text/plain; charset="utf-8" Content-ID: <488B3FB23A8EEE4BBCAE549A146B807E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 20:53:27 -0000 T24gNC84LzE1LCAxOjM5IFBNLCAiVG9lcmxlc3MgRWNrZXJ0IChlY2tlcnQpIiA8ZWNrZXJ0QGNp c2NvLmNvbT4gd3JvdGU6DQoNCj5EYW5pZWwsDQo+DQo+YSkgSSB0aGluayBvbmUgaG9wZSBvZiBT UFVEcyBkZXNpZ24gaXMgdG8gbWFrZSBVRFAgbG9vayBlbm91Z2ggbGlrZQ0KPiAgIFRDUCB0byBw ZXJzdWFkZSBGV3MgKGFuZCBzaW1pbGFyIG1pZGRsZWJveGVzKSB0byBwb2xpY2UgLyBwZXJtaXQg aXQNCj4gICBhcyB3ZWxsIGFzIFRDUCBmbG93cyBhcmUgcG9saWNlZC9wZXJtaXR0ZWQuDQoNClll cy4gIEluIHRhbGtpbmcgd2l0aCBlbnRlcnByaXNlIGZpcmV3YWxsIGFkbWlucywgdGhleSdyZSBj b21mb3J0YWJsZSB3aXRoIHRoZXNlIHByb3BlcnRpZXMgb2YgVENQOg0KDQotIHRoZXkncmUgc3Vy ZSB3aGljaCBpbnRlcmZhY2UgdGhlIGludGVudCB0byBzdGFydCBhbiBhc3NvY2lhdGlvbiBjYW1l IGluIG9uDQotIHRoZXkncmUgcHJldHR5IHN1cmUgdGhhdCBzdWJzZXF1ZW50IHBhY2tldHMgbWF0 Y2ggdGhhdCBpbml0aWFsIGludGVudA0KLSB0aGV5J3JlIHByZXR0eSBzdXJlIHRoYXQgaWYgYSBi b3ggZ29lcyBkb3duIGNvbWVzIGJhY2sgdXAsIG9yIGEgbmV3IGJveCB0YWtlcyB0aGUgb2xkIG9u ZSdzIGFkZHJlc3MgbGlzdGVuaW5nIG9uIHRoZSBzYW1lIHBvcnQsIHRoYXQgdGhlIGhvc3Qgd2ls bCBiZSBhYmxlIHRvIHJlamVjdCB0cmFmZmljIGxlZnQgb3ZlciBmcm9tIGFuIG9sZCBhc3NvY2lh dGlvbg0KLSB0aGV5IGtub3cgd2hlbiB0byBjbGVhbiB1cCBzdGF0ZQ0KLSB0aGV5IGRvbid0IGZl ZWwgdGhlIG5lZWQgdG8gc2V0IGFzIGFnZ3Jlc3NpdmUgdGltZW91dHMgYXMgdGhleSBjdXJyZW50 bHkgZG8gZm9yIFVEUCwgd2hpY2ggd291bGQgY2F1c2UgYXBwcyB0byBzZW5kIGxvdHMgb2YgZXh0 cmEga2VlcC1hbGl2ZXMNCg0KRnJvbSBhIGNlcnRhaW4gcGVyc3BlY3RpdmUsIGl0IGRvZXNuJ3Qg bmVjZXNzYXJpbHkgbWF0dGVyIGlmIHdlIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB0aGVtIHRoYXQg dG9kYXkncyBpbXBsaWNpdCBoZXVyaXN0aWNzIGFyZSBub3QgZ29vZCBlbm91Z2guICBXZSBoYXZl IGV2aWRlbmNlIHRoYXQgdGhlcmUgYXJlIGVub3VnaCBjb3Jwb3JhdGUgZmlyZXdhbGwgYWRtaW5z IGhhdmUgc2ltaWxhciBmZWVsaW5ncywgcGFydGljdWxhcmx5IGluIHBsYWNlcyB3aGVyZSBmb2xr cyB0aGF0IHdhbnQgdG8gZGVwbG95IHN0YW5kYXJkcy1iYXNlZCBXZWJSVEMgc29sdXRpb25zIChl LmcuKSwgdGhhdCBJIGJlbGlldmUgd2UgbmVlZCB0byB0YWtlIHRoZWlyIHBlcmNlcHRpb25zIGlu dG8gYWNjb3VudC4gIFRoZSBhcHByb2FjaCB0aGF0IFNQVUQgY3VycmVudGx5IHRha2VzIGlzIHRv IHNtZWxsIGVub3VnaCBsaWtlIFRDUCBmcm9tIGEgcG9saWN5IHBlcnNwZWN0aXZlIHRoYXQgd2Ug Y2FuIGdldCBjb3Jwb3JhdGUgZmlyZXdhbGwgYWRtaW5zIHRvIGFsbG93IHRoZSB0cmFmZmljIGJ5 IHBvbGljeS4NCg0KSW4gb3RoZXIgd29yZHM6IHRoZXNlIGFyZSBwb3RlbnRpYWxseSBkZXBsb3lt ZW50IHJlcXVpcmVtZW50cywgbm90IHRlY2huaWNhbCByZXF1aXJlbWVudHMuDQoNCi0tIA0KSm9l IEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Wed Apr 8 14:31:40 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEA61B3395 for ; Wed, 8 Apr 2015 14:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 9c2lhG1xzsX6 for ; Wed, 8 Apr 2015 14:31:37 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (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 B47CB1B36D4 for ; Wed, 8 Apr 2015 14:31:28 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so21396734pab.2 for ; Wed, 08 Apr 2015 14:31:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xcKVWEWFQZxpeIt5n+iam4zdgCRu4R/K18XzYfQS8Tw=; b=bh3lZt+0TwIOZbmv/Ox2Qt9LWuv8oiYPNoLrsdQsORL1uoPdC9m0Un8gxTaeGMGFik Nghll4NgIKyefVKSg7kVKfHd4YoG8gG/4hMknBhZSLUpejK+0n8gTRab+M7+Y5lXrPe5 v/s9UMNI+w8vdGOyf3tNenxV3GWKl84kK57ANBZqQ2Cul0hxBd4csS+cOYbyWPHsOEMF xlfIcJnwYEz/FChcUWvaW0nxy3FzzMRHjdcGesS/TXXjEqGFLAfL53L1K34cjxqXWy+v 88xsfPBjv1Fb40UB6HAJ0QGS34JXXtkN5qzpQWo/vm1D0nFoWcyiC0sS/UetBLUJDAmR 5Lew== X-Gm-Message-State: ALoCoQlK8Yrt9VSP0ZAJvMu8Dq+w7w4QUDH46bG0dvXQyC273KwZYKi/5DIglG0XbbxM1G0woPW/ X-Received: by 10.70.34.196 with SMTP id b4mr50173525pdj.157.1428528688394; Wed, 08 Apr 2015 14:31:28 -0700 (PDT) Received: from Macintosh-2.local (67-207-110-172.static.wiline.com. [67.207.110.172]) by mx.google.com with ESMTPSA id r4sm12267197pdg.11.2015.04.08.14.31.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 14:31:27 -0700 (PDT) Message-ID: <55259E2F.8030604@nexenta.com> Date: Wed, 08 Apr 2015 14:31:27 -0700 From: Caitlin Bestler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: spud@ietf.org References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <09D0D481-9380-42CA-94B1-895EC9E51428@cisco.com> In-Reply-To: <09D0D481-9380-42CA-94B1-895EC9E51428@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:31:39 -0000 On 4/8/15 1:53 PM, Joe Hildebrand (jhildebr) wrote: > On 4/8/15, 1:39 PM, "Toerless Eckert (eckert)" wrote: > >> Daniel, >> >> a) I think one hope of SPUDs design is to make UDP look enough like >> TCP to persuade FWs (and similar middleboxes) to police / permit it >> as well as TCP flows are policed/permitted. > Yes. In talking with enterprise firewall admins, they're comfortable with these properties of TCP: > > - they're sure which interface the intent to start an association came in on > - they're pretty sure that subsequent packets match that initial intent > - they're pretty sure that if a box goes down comes back up, or a new box takes the old one's address listening on the same port, that the host will be able to reject traffic left over from an old association > - they know when to clean up state > - they don't feel the need to set as aggressive timeouts as they currently do for UDP, which would cause apps to send lots of extra keep-alives > > From a certain perspective, it doesn't necessarily matter if we completely agree with them that today's implicit heuristics are not good enough. We have evidence that there are enough corporate firewall admins have similar feelings, particularly in places where folks that want to deploy standards-based WebRTC solutions (e.g.), that I believe we need to take their perceptions into account. The approach that SPUD currently takes is to smell enough like TCP from a policy perspective that we can get corporate firewall admins to allow the traffic by policy. > > In other words: these are potentially deployment requirements, not technical requirements. Joe's analysis highlights an important point - there is no need for SPUD to be better than TCP. If TCP is vulnerable to off-path reset attacks, then it would be ok for SPUD to be vulnerable. We just have to avoid making SPUD *more* vulnerable. > From nobody Wed Apr 8 15:04:20 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF5B1A901F for ; Wed, 8 Apr 2015 15:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Y92gC3wXf_Lw for ; Wed, 8 Apr 2015 15:04:15 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0721A9007 for ; Wed, 8 Apr 2015 15:04:13 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 710FC1A01CB; Thu, 9 Apr 2015 00:03:41 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7853201E-4B62-415C-BEE0-C9594A924058"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: <87iod631nv.fsf@alice.fifthhorseman.net> Date: Thu, 9 Apr 2015 00:03:40 +0200 Message-Id: References: <87iod631nv.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:04:18 -0000 --Apple-Mail=_7853201E-4B62-415C-BEE0-C9594A924058 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Daniel, all, Thanks for your comments; commentcomments per tradition inline... > On 08 Apr 2015, at 20:39, Daniel Kahn Gillmor = wrote: >=20 > Hi folks-- >=20 > Thanks to those who organized the SPUD BoF at IETF 92. Despite having > some serious big-picture concerns about SPUD overall, I sympathize = with > the general goal of facilitating encrypting more traffic to protect = the > confidentiality, integrity and anonymity of Internet communications, = so > i appreciate the effort. >=20 > I'll write up the big-picture concerns separately, but right now i = plan > to focus on some of the concrete details that i find unconvincing = about > the idea and the associated proposals. I'll try to keep each detail > relatively succinct. >=20 > This message is about the need for open/close in SPUD, which in the > presentations i saw was frequently the first example brought out to > explain what advantages SPUD can offer to existing on-path equipment. >=20 > These signals don't seem to provide any useful advantages to me: Open = is > superfluous, and Close is unreliable. >=20 > Open is superfluous > ------------------- >=20 > Given the existing 5-tuple, on-path equipment trivially knows when a > flow starts already: it is a 5-tuple that they haven't seen before. = If > you want to maintain a distinction between a one-side-opened flow and = a > replied flow, this is also traceable by looking at the 5-tuple. It's > not clear that the "open" signal gives on-path equipment any = additional > useful information that it didn't have already from the 5-tuple. I'll defer to Joe's answer on what makes firewall guys happy. :) I think part of the problem is we're trying to draw a boundary we don't = quite understand between the "over" transport (the thing inside SPUD) = and the "minimal common" transport that SPUD provides. Which is why = we're putting effort into a prototype, on which see my next message = (hopefully somewhen tomorrow...) The explicit signaling of OPEN to devices on path is an accident of the = design of TCP. There are devices out there that treat SYNs specially, = and the point of signaling OPEN is, in the first order, to allow those = devices to do those things they do on SYN. On the other hand, reacting = to SYN specially is one of the mechanisms by which these devices make = assumptions that can break connectivity, so maybe this is one of those = requirements that isn't really a requirement, but rather something = common to the over-transport. Another way to look at OPEN is that it is the inverse of signaling the = running state. As a middlebox, seeing packets on a tube for which you = didn't see an OPEN or an ACK means: (1) you rebooted or got a new address (2) routing is different and you're seeing the middle of a flow (3) someone is messing with you It also means that you're missing any ADEC information associated with = the tube, and cannot tell whether the tube is valid. It's also not 100% = clear you can do anything useful with these. SPUD's ACK (roughly TCP SYN/ACK) is more interesting. A SYN/ACK in = proper response to a SYN means that someone on the other side of the = firewall decided a connection could proceed, or more mundanely means = there is now actually state on the endpoint so any state the network = needs should be there too. For bidirectional transports (i.e., for every = transport one should be running over SPUD, since congestion control = requires feedback, as does proof of reverse reachability to reduce = spoofing) it might be that ACK is sufficient to get us what we need. (In = reviewing that paragraph, we probably also need to name it something = other than ACK.) > Close is unreliable > ------------------- >=20 > One of the reasons on-path equipment would like a "close" signal is so > that they know when to tear down associations that are no longer = needed. > This would reduce memory consumption and make a device more resilient = to > DoS attacks that exhaust its connection table. Without "close", the > on-path equipment has to rely on timers to decide when to tear down = the > connection. >=20 > Unfortunately, we can't rely on endpoints to send Close. Legitimate > endpoints crash, run out of power, or have their network connectivity > cut. Another reason: transports running over SPUD might not even have a = signal that maps to CLOSE. > So on-path equipment needs to maintain timers anyway if they're > tracking flow state instead of just passing IP traffic statelessly. Yep. Nobody's saying you can chuck the timers with CLOSE. You can set = faster timers once you've seen one, and use state space only for the = exceptions. Right now, just looking at a bare UDP datagram, you can't. It is important to note that if CLOSE is done right, and the active tube = ID space remains sufficiently sparse, then only devices on the path or = entities cooperating with them -- i.e., those that are in position = trivially block or inject traffic -- can fake a CLOSE: you have to be = able to fake a valid tube ID. > And > in a DoS scenario, it's trival for an actively malicious end-point to > send lots of "open" messages without ever sending a "close", so it > doesn't protect against DoS either. I don't think we can have devices on path that keep any sort of state = without defenses against state exhaustion, and I don't know that it's = useful to design those into a signaling encapsulation. You still have to = have reverse-reachability, cookies can help, and you probably need some = sort of heuristic for rate-limiting. Indeed, these all speak toward = making ACK the important OPEN. Cheers, Brian --Apple-Mail=_7853201E-4B62-415C-BEE0-C9594A924058 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 iQEcBAEBCgAGBQJVJaW8AAoJENt3nsOmbNJcWfgH/0g4PMU21cIjeyWlcybg5Btk 3uv2/4ISIxzVk1eOJdUkwo+dgan/v0x5ZdOAsQ7Uyn92hHBktN/oM6A1I3qvArzq 80t2YrY0XQTg+yVlClU6a2+py4o3AlZlDtUSsE6/DoVbqlPUTfOl6+M9nGkHTSvP 1UbivBMNUkV8nMXX8x5x8QztxQM2yRhGiBnsDRnGUwXuXW0BWn6jIe2NndJf4lsO Tw17zAzOZejjo+SybbiRpheC7zqFgRtHIt553Tum0fpfH3UhQkfBkhKiNkqglHXO k0VhrADLf9hM+OsWk5dXQyPuq/Tgs6KW6bXja98dmEPjPS3Hah6LCeKRfXPaZDg= =soIT -----END PGP SIGNATURE----- --Apple-Mail=_7853201E-4B62-415C-BEE0-C9594A924058-- From nobody Wed Apr 8 15:12:01 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36341A9027 for ; Wed, 8 Apr 2015 15:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 A94BMZbgTB1b for ; Wed, 8 Apr 2015 15:11:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B39D21A9028 for ; Wed, 8 Apr 2015 15:11:58 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B1A3DF984; Wed, 8 Apr 2015 18:11:56 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 485902011F; Wed, 8 Apr 2015 17:11:45 -0500 (CDT) From: Daniel Kahn Gillmor To: "Joe Hildebrand \(jhildebr\)" , "Toerless Eckert \(eckert\)" In-Reply-To: <09D0D481-9380-42CA-94B1-895EC9E51428@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <09D0D481-9380-42CA-94B1-895EC9E51428@cisco.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 08 Apr 2015 18:11:45 -0400 Message-ID: <874moq2rtq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:12:00 -0000 On Wed 2015-04-08 16:53:24 -0400, Joe Hildebrand (jhildebr) wrote: > On 4/8/15, 1:39 PM, "Toerless Eckert (eckert)" wrote: > >>Daniel, >> >>a) I think one hope of SPUDs design is to make UDP look enough like >> TCP to persuade FWs (and similar middleboxes) to police / permit it >> as well as TCP flows are policed/permitted. > > Yes. In talking with enterprise firewall admins, they're comfortable with these properties of TCP: > > - they're sure which interface the intent to start an association came in on This is true of UDP today. > - they're pretty sure that subsequent packets match that initial intent This is also true of UDP today; responses to the same 5-tuple (with source and dest swapped) provide a "pretty sure" match. > - they're pretty sure that if a box goes down comes back up, or a new > box takes the old one's address listening on the same port, that the > host will be able to reject traffic left over from an old association Surely this is a matter for endpoints and not for middleboxes, and dependent on the protocol implemented by the listener? For stateless listeners on an endpoint, they shouldn't mind seeing traffic from an old "association" because no state is associated with it. For stateful listeners, they can simply discard traffic that doesn't align with their internal state. > - they know when to clean up state This is untrue of either TCP or UDP today in an absolute sense. In both cases, they must each rely on timeouts because either peer can fall off-net for many different reasons that are beyond anyone's control. > - they don't feel the need to set as aggressive timeouts as they > currently do for UDP, which would cause apps to send lots of extra > keep-alives So they're willing to permit longer timeouts for raw TCP SYNs than they do for UDP? That sounds like a trivial state exhaustion attack waiting to happen. If they treat an unacknowledged TCP SYN with an aggressive timeout, but then lengthen the timeout after seeing a SYN/ACK, then surely they can just treat an unreplied UDP 5-tuple with the aggressive timeout, and lengthen it when they see a response? This doesn't require any on-wire format change. > From a certain perspective, it doesn't necessarily matter if we > completely agree with them that today's implicit heuristics are not > good enough. We have evidence that there are enough corporate > firewall admins have similar feelings, particularly in places where > folks that want to deploy standards-based WebRTC solutions (e.g.), > that I believe we need to take their perceptions into account. The > approach that SPUD currently takes is to smell enough like TCP from a > policy perspective that we can get corporate firewall admins to allow > the traffic by policy. > > In other words: these are potentially deployment requirements, not > technical requirements. This argument is also unconvincing to me. It sounds like you're saying that we cannot rely on this group of administrators to make reasonable decisions about how to operate their equipment on the basis of the data that they currently have, so we're going to do some unnecessary things to the bits on the wire that will convince them to make reasonable decisions on the basis of some other unnecessary data. Why should i believe that this will be the eventual outcome? A group of administrators has already provided evidence that they're unwilling to consider reasonable approaches with data format A; why would equivalent data format B suggest they would do anything different? --dkg From nobody Wed Apr 8 15:19:00 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7653A1A905A for ; Wed, 8 Apr 2015 15:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 b0SoZvF4Qzb8 for ; Wed, 8 Apr 2015 15:18:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4561A9056 for ; Wed, 8 Apr 2015 15:18:56 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (0.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (0.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.130.23; Wed, 8 Apr 2015 22:18:34 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([0.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([0.160.96.17]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 22:18:34 +0000 From: Christian Huitema To: Brian Trammell , Daniel Kahn Gillmor Thread-Topic: [Spud] SPUD's open/close are unconvincing Thread-Index: AQHQcitjyluT4qW5rECm5Hf5sMmnv51Dq2YAgAABoVA= Date: Wed, 8 Apr 2015 22:18:34 +0000 Message-ID: References: <87iod631nv.fsf@alice.fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::4] authentication-results: trammell.ch; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(2900100001)(50986999)(92566002)(122556002)(74316001)(62966003)(2950100001)(102836002)(87936001)(40100003)(77156002)(33656002)(2656002)(46102003)(106116001)(86362001)(54356999)(76176999)(76576001)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0540846A1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 22:18:34.5994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:18:58 -0000 > SPUD's ACK (roughly TCP SYN/ACK) is more interesting. A SYN/ACK in proper > response to a SYN means that someone on the other side of the firewall de= cided > a connection could proceed, or more mundanely means there is now actually > state on the endpoint so any state the network needs should be there too.= For > bidirectional transports (i.e., for every transport one should be running= over > SPUD, since congestion control requires feedback, as does proof of revers= e > reachability to reduce spoofing) it might be that ACK is sufficient to ge= t us what > we need. (In reviewing that paragraph, we probably also need to name it > something other than ACK.) The mapping to actual transport semantics is not entirely clear. Many trans= port protocols implement some kind of protection against SYN Flooding. One = popular such protection is a cookie challenge. So we get a connect/SYN requ= est, a challenge response, a confirmation of the challenge, and only then t= he actual accept by the server. Which of the server's message map to ACK? T= he challenge, or the actual confirmation? > ... > > So on-path equipment needs to maintain timers anyway if they're > > tracking flow state instead of just passing IP traffic statelessly. >=20 > Yep. Nobody's saying you can chuck the timers with CLOSE. You can set fas= ter > timers once you've seen one, and use state space only for the exceptions.= Right > now, just looking at a bare UDP datagram, you can't. Even that is not obvious. What kind of value do you give to the "fast timer= ?" What if the mobile client is asleep when the fake CLOSE arrives, and can= not invalidate it quickly by sending more traffic?=20 > It is important to note that if CLOSE is done right, and the active tube = ID space > remains sufficiently sparse, then only devices on the path or entities co= operating > with them -- i.e., those that are in position trivially block or inject t= raffic -- can > fake a CLOSE: you have to be able to fake a valid tube ID. Please take a look at the Quantum attacks, which combine passive listening = on the path with injection from the side. There is a difference between "bl= ock traffic" and "inject traffic." Only the forwarding agents can effective= ly block traffic. Passive listeners can inject traffic without cooperating = with the forwarding agents. -- Christian Huitema From nobody Wed Apr 8 15:21:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32B1A9062 for ; Wed, 8 Apr 2015 15:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6] 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 nJU0jUsoqTkQ for ; Wed, 8 Apr 2015 15:21:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A43081A9059 for ; Wed, 8 Apr 2015 15:21:24 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 87189F984; Wed, 8 Apr 2015 18:21:22 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 4953C20191; Wed, 8 Apr 2015 17:21:21 -0500 (CDT) From: Daniel Kahn Gillmor To: Toerless Eckert In-Reply-To: <20150408193920.GD24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 08 Apr 2015 18:21:21 -0400 Message-ID: <871tju2rdq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:21:25 -0000 Hi Toerless-- On Wed 2015-04-08 15:39:21 -0400, Toerless Eckert wrote: > a) I think one hope of SPUDs design is to make UDP look enough like > TCP to persuade FWs (and similar middleboxes) to police / permit it > as well as TCP flows are policed/permitted. > > b) If you don't like how it works, let me generalize the question, > would like to hear your (and others) answers: > > What is the best possible design we can do to make UDP flows > be equal or better permissible across WELL BEHAVED FW and similar > middleboxes ? Please define "WELL BEHAVED"as part of your answer. As i wrote to Joe, i'm not convinced that this is an answerable question considering that no one has provided a technical argument yet for why the enterprise firewall operators can't already do what we're talking about here. > c) If i read it correctly, SPUD can > > a) set up potentially multiple independent pipes across the same 5-tuple. > b) A single pipe can go across different 5-tuples (multipath/mobility). > > These two features should explain why tracking 5-tuple as you > suggest alone would not be sufficient. > > Btw: I am a fan of b), i don't think a) should be encouraged given > experience with RTCweb. In that sense, the total number of > pipes would even be equal or smaller than the number of 5 tuples. This is an interesting point, thanks. I'd be curious to hear more details about the RTCweb experience that have convinced you that (a) should not be encouraged. The trouble with (b), of course, is that in the multipath or mobility case, the tube will continue its flow over different network segments, which violates the goals people have described for open and close. As i move to a new path, i'm deliberately not sending a Close message (because i want to keep the tube open, right?) -- so what do the middleboxes do? And after i've moved to a new network and want to continue the same tube, surely i won't indicate that the flow is opening (it's already open). As a result, the equipment on the new path won't see the Open message -- should they discard it now? These arrangements seem in conflict to me. Regards, --dkg > P.S.: Cool domain name. Is that indicative of the role you're planning > to take in the discussion ? ;-))) (sorry, i can never resists these questions). :) From nobody Wed Apr 8 16:46:11 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AB71B347D for ; Wed, 8 Apr 2015 16:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 4RG4zHqTZXmB for ; Wed, 8 Apr 2015 16:46:07 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 2A1BC1B36C9 for ; Wed, 8 Apr 2015 16:46:07 -0700 (PDT) Received: by igblo3 with SMTP id lo3so52190687igb.0 for ; Wed, 08 Apr 2015 16:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dRcc6NQT9ZNzqbx0iAZCu+GYdqchga9Zr1Bzgt/O72c=; b=dXKmtNYqTO3N5MPtcgP3R6zbJaowU7TmntTNsAbt6LQaDLU2LanZqDpdMEhzIUgC1f 750cjzYow8vOO2mEWbducXcs1d15jEOSA3zv8ElajL3Zft5baqoKSrE12jFs0fTlRwuT /zBlu3WdL9zugkjYPj37TRLpExF+akWUDTaWm6SM9txfii3Pa+axRRQ2h2ezAwEGVriU IlgqD1F1ntSt4bVXYwJS8qClX/1sDRm+ulUI4/FZMzLPGAyZGXOARsE1vvPHOxYyg9Fm OGQ2G74zuH79GLSHVFv/WfUEkd+Dz/TcpFwVmflYM+CDfeMpvjvvQbjzIxdR3PGwoeN4 0gaA== 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:date :message-id:subject:from:to:cc:content-type; bh=dRcc6NQT9ZNzqbx0iAZCu+GYdqchga9Zr1Bzgt/O72c=; b=C/bv9tmmeUKUE2bQz5PDnqHBVxzEe8Cfvcck+sYHo1b9p1MPtW9BFYDjDYQ4sLavWP DYBqHMvVTZys8oq+TlyehkLs8wdOOC5v25oDN5vedJ308R/5jv1vq3vmfiUHvOEePQfq nlvFVRjhPm4KM/9bkE2AV/xekPxR2DzPcvdt9TqN/cr5Lf0llUIWVSoO1clOjhHI88a4 gx1yb+Yu/Dhzf8AeFbEmJuEDOmH5KJ69olOXF5BVhCsw7gBhLWSTPrzA4kIK8x15I/W5 GUXz9QauN/XKYaMLr/Vn1/tMeTZlP8ujk+7Tb8jP8kO6AqFf1AaXvNr9r2tVdeocMy8C W47A== X-Gm-Message-State: ALoCoQn8C2xhEe/PNA+pLCY0dQu6kmFvAW4PYpHMMP9YQ6c8qLu4MEujvNlspJsbwPKrJxtUG/ru MIME-Version: 1.0 X-Received: by 10.50.56.106 with SMTP id z10mr15802715igp.8.1428536766268; Wed, 08 Apr 2015 16:46:06 -0700 (PDT) Received: by 10.50.45.41 with HTTP; Wed, 8 Apr 2015 16:46:06 -0700 (PDT) In-Reply-To: <874moq2rtq.fsf@alice.fifthhorseman.net> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <09D0D481-9380-42CA-94B1-895EC9E51428@cisco.com> <874moq2rtq.fsf@alice.fifthhorseman.net> Date: Wed, 8 Apr 2015 16:46:06 -0700 Message-ID: From: Jana Iyengar To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=089e0158afa680b5fa05133f2215 Archived-At: Cc: "Toerless Eckert \(eckert\)" , "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:46:10 -0000 --089e0158afa680b5fa05133f2215 Content-Type: text/plain; charset=UTF-8 Hi all, One higher-order point: This conversation seems to refer to middlebox admins as outsiders and represents them as an ossified whole. If this new architecture is to be a end-middle-end architecture, the middle needs to be represented in a technical debate about the value of new protocol machinery. I would sincerely love to see that happen. I think there's a good bit of serious architectural work that can be done here, but this requires wrangling with hard questions about trust, delegation, and placement of network functions. I fear that discussions on what exact bits to expose so that middlebox admins don't turn into fire-breathing monsters misses the larger architectural questions. It's not clear to me that we should negotiate with middlebox admins on what bits they want -- I'd like some degree of engagement on exactly why they want it. I'm not keen to see the middlebox admin's wishlist of what headers they'd like to see. I'm substantially more interested in understanding the network functions they are looking for. Chances are these are implementable without the information they think they need. If not, let's make that case -- one network function at a time -- do a cost-benefit analysis for the good of the Internet, and decide whether to expose any bits. dkg has quite nicely said many of the things I've wanted to say below; I'll re-echo these and I'll add a couple of comments inline. > Yes. In talking with enterprise firewall admins, they're comfortable > with these properties of TCP: > > > > - they're sure which interface the intent to start an association came > in on > > This is true of UDP today. +1. > > > - they're pretty sure that subsequent packets match that initial intent > > This is also true of UDP today; responses to the same 5-tuple (with > source and dest swapped) provide a "pretty sure" match. +1. > > > - they're pretty sure that if a box goes down comes back up, or a new > > box takes the old one's address listening on the same port, that the > > host will be able to reject traffic left over from an old association > > Surely this is a matter for endpoints and not for middleboxes, and > dependent on the protocol implemented by the listener? For stateless > listeners on an endpoint, they shouldn't mind seeing traffic from an old > "association" because no state is associated with it. For stateful > listeners, they can simply discard traffic that doesn't align with their > internal state. +1. > > > - they know when to clean up state > > This is untrue of either TCP or UDP today in an absolute sense. In both > cases, they must each rely on timeouts because either peer can fall > off-net for many different reasons that are beyond anyone's control +1. > > - they don't feel the need to set as aggressive timeouts as they > > currently do for UDP, which would cause apps to send lots of extra > > keep-alives > > So they're willing to permit longer timeouts for raw TCP SYNs than they > do for UDP? That sounds like a trivial state exhaustion attack waiting > to happen. If they treat an unacknowledged TCP SYN with an aggressive > timeout, but then lengthen the timeout after seeing a SYN/ACK, then > surely they can just treat an unreplied UDP 5-tuple with the aggressive > timeout, and lengthen it when they see a response? This doesn't require > any on-wire format change. +1. I'll add that it wouldn't be surprising for clients to disappear or for servers to drop TCP connections without sending a FIN or an RST, for a variety of reasons. (As it turns out, this can be energy-saving for mobile devices that don't have to wake the radio up only to receive and process a FIN! See: http://conferences.sigcomm.org/co-next/2013/program/p211.pdf.) > > From a certain perspective, it doesn't necessarily matter if we > > completely agree with them that today's implicit heuristics are not > > good enough. We have evidence that there are enough corporate > It obviously does matter if we disagree with them. We're considering a rework of the Internet's architecture -- I don't think this is what you're saying, but at what point did we decide to take their needs as absolute? "They" need to make technical arguments about their needs, if more information is to be exposed for their use. > firewall admins have similar feelings, particularly in places where > > folks that want to deploy standards-based WebRTC solutions (e.g.), > > that I believe we need to take their perceptions into account. The > > approach that SPUD currently takes is to smell enough like TCP from a > > policy perspective that we can get corporate firewall admins to allow > > the traffic by policy. > Doesn't it seem silly that we will be engaging with corporate firewall admins, but only to learn that *they think* our traffic needs to look like TCP for them to be comfortable with it? Their perceptions of TCP are most likely ossified, and quite possibly wrong -- what do we do then? (Perhaps we should run the "Underhanded TCP Contest" -- make crazy stuff happen but look like TCP on the wire :-)) TCP FastOpen and Minion both challenge prior notions of what was (incorrectly but commonly) considered TCP behavior. I would be quite disappointed if we were to enshrine this ossification in a wg, and for non-TCP protocols too! This wouldn't be evolution, this would be ossification on steroids. > In other words: these are potentially deployment requirements, not > > technical requirements. > > This argument is also unconvincing to me. It sounds like you're saying > that we cannot rely on this group of administrators to make reasonable > decisions about how to operate their equipment on the basis of the data > that they currently have, so we're going to do some unnecessary things > to the bits on the wire that will convince them to make reasonable > decisions on the basis of some other unnecessary data. > > Why should i believe that this will be the eventual outcome? A group of > administrators has already provided evidence that they're unwilling to > consider reasonable approaches with data format A; why would equivalent > data format B suggest they would do anything different? > +1. - jana --089e0158afa680b5fa05133f2215 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

One higher-order point: Th= is conversation seems to refer to middlebox admins as outsiders and represe= nts them as an ossified whole. If this new architecture is to be a end-midd= le-end architecture, the middle needs to be represented in a technical deba= te about the value of new protocol machinery. I would sincerely love to see= that happen. I think there's a good bit of serious architectural work = that can be done here, but this requires wrangling with hard questions abou= t trust, delegation, and placement of network functions. I fear that discus= sions on what exact bits to expose so that middlebox admins don't turn = into fire-breathing monsters misses the larger architectural questions.

It's not clear to me that we should negotia= te with middlebox admins on what bits they want -- I'd like some degree= of engagement on exactly why they want it. I'm not keen to see the mid= dlebox admin's wishlist of what headers they'd like to see. I'm= substantially more interested in understanding the network functions they = are looking for. Chances are these are implementable without the informatio= n they think they need.=C2=A0 If not, let's make that case -- one netwo= rk function at a time -- do a cost-benefit analysis for the good of the Int= ernet, and decide whether to expose any bits.

dkg has quite nicely said many of the thin= gs I've wanted to say below; I'll re-echo these and I'll add a = couple of comments inline.

=
> Yes.=C2=A0 In talking with enterprise firewall admins, they're com= fortable with these properties of TCP:
>
> - they're sure which interface the intent to start an association = came in on

This is true of UDP today.

+1.
=
=C2=A0

> - they're pretty sure that subsequent packets match that initial i= ntent

This is also true of UDP today; responses to the same 5-tuple (with<= br> source and dest swapped) provide a "pretty sure" match.

+1.
=C2=A0

> - they're pretty sure that if a box goes down comes back up, or a = new
>=C2=A0 =C2=A0box takes the old one's address listening on the same = port, that the
>=C2=A0 =C2=A0host will be able to reject traffic left over from an old = association

Surely this is a matter for endpoints and not for middleboxes, and dependent on the protocol implemented by the listener?=C2=A0 For stateless<= br> listeners on an endpoint, they shouldn't mind seeing traffic from an ol= d
"association" because no state is associated with it.=C2=A0 For s= tateful
listeners, they can simply discard traffic that doesn't align with thei= r
internal state.

+1.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
> - they know when to clean up state

This is untrue of either TCP or UDP today in an absolute sense.=C2= =A0 In both
cases, they must each rely on timeouts because either peer can fall
off-net for many different reasons that are beyond anyone's control

+1.
=C2=A0
> - they don't feel the need to set as aggressive timeouts as they > currently do for UDP, which would cause apps to send lots of extra
> keep-alives

So they're willing to permit longer timeouts for raw TCP SYNs th= an they
do for UDP?=C2=A0 That sounds like a trivial state exhaustion attack waitin= g
to happen.=C2=A0 If they treat an unacknowledged TCP SYN with an aggressive=
timeout, but then lengthen the timeout after seeing a SYN/ACK, then
surely they can just treat an unreplied UDP 5-tuple with the aggressive
timeout, and lengthen it when they see a response?=C2=A0 This doesn't r= equire
any on-wire format change.

+1. I'll add= that it wouldn't be surprising for clients to disappear or for servers= to drop TCP connections without sending a FIN or an RST, for a variety of = reasons. (As it turns out, this can be energy-saving for mobile devices tha= t don't have to wake the radio up only to receive and process a FIN! Se= e: http://conferences.sigcomm.org/co-next/2013/program/p211.pdf.)
=C2=A0
> From a certain perspective, it doesn't necessarily matter if we > completely agree with them that today's implicit heuristics are no= t
> good enough.=C2=A0 We have evidence that there are enough corporate

It obviously does matter if we dis= agree with them. We're considering a rework of the Internet's archi= tecture --=C2=A0I don't think this is what you're saying, but=C2=A0= at what point did we decide to take their needs as absolute? "They&quo= t; need to make technical arguments about their needs, if more information = is to be exposed for their use.

> firewall admins have similar feelings, particularly in places where > folks that want to deploy standards-based WebRTC solutions (e.g.),
> that I believe we need to take their perceptions into account.=C2=A0 T= he
> approach that SPUD currently takes is to smell enough like TCP from a<= br> > policy perspective that we can get corporate firewall admins to allow<= br> > the traffic by policy.

Does= n't it seem silly that we will be engaging with corporate firewall admi= ns, but only to learn that *they think* our traffic needs to look like TCP = for them to be comfortable with it? Their perceptions of TCP are most likel= y ossified, and quite possibly wrong -- what do we do then? (Perhaps we sho= uld run the "Underhanded TCP Contest" -- make crazy stuff happen = but look like TCP on the wire :-)) TCP FastOpen and Minion both challenge p= rior notions of what was (incorrectly but commonly) considered TCP behavior= . I would be quite disappointed if we were to enshrine this ossification in= a wg, and for non-TCP protocols too! This wouldn't be evolution, this = would be ossification on steroids.

> In other words: these are potentially deployment requirements, not
> technical requirements.

This argument is also unconvincing to me.=C2=A0 It sounds like you&#= 39;re saying
that we cannot rely on this group of administrators to make reasonable
decisions about how to operate their equipment on the basis of the data
that they currently have, so we're going to do some unnecessary things<= br> to the bits on the wire that will convince them to make reasonable
decisions on the basis of some other unnecessary data.

Why should i believe that this will be the eventual outcome?=C2=A0 A group = of
administrators has already provided evidence that they're unwilling to<= br> consider reasonable approaches with data format A; why would equivalent
data format B suggest they would do anything different?

+1.

- jana

=C2=A0
--089e0158afa680b5fa05133f2215-- From nobody Wed Apr 8 18:22:36 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDC31ACD8D for ; Wed, 8 Apr 2015 18:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 YLaRBN9XXR1v for ; Wed, 8 Apr 2015 18:22:33 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62AF1ACD8B for ; Wed, 8 Apr 2015 18:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6231; q=dns/txt; s=iport; t=1428542553; x=1429752153; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=KD0zFsiK3Xnw34fQdSahOBh5WL+Dn9H+gs6x3vWFzE0=; b=PVeED4ROc1oHIPPASAdzJbhwSGWNkDYB4yzs+pTkh9FgLtiQMGAGx2cj szXlVzdcVMR4EeCH/2LH/ksA1YObAuJ+q+hv87axh6VKdATJkQb6Dz0Yo HGzgwQeLP4Tf4U6KJYHdTnielg2jwiZ0Hx+piCVvTW1WnJ6+qrnqAJm5o I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5BQCs0yVV/5pdJa1cgwjMewKBLzwQAQEBAQEBAX2EHwEBAQMBJxM/BQsLEgYJJQ8FNRSINQjMfwEBAQEBAQEBAQEBAQEBAQEBAQEBGIosf4R8B4QtBYsni2yDZwGBHYM3gmOJWoNKIoIDHIFwHoJ0AQEB X-IronPort-AV: E=Sophos;i="5.11,547,1422921600"; d="scan'208";a="139487989" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 09 Apr 2015 01:22:32 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t391MVdU020587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 01:22:31 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t391MU1w027017; Wed, 8 Apr 2015 18:22:31 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t391MT6U027014; Wed, 8 Apr 2015 18:22:29 -0700 Date: Wed, 8 Apr 2015 18:22:29 -0700 From: Toerless Eckert To: Daniel Kahn Gillmor Message-ID: <20150409012229.GG24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871tju2rdq.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 01:22:35 -0000 On Wed, Apr 08, 2015 at 06:21:21PM -0400, Daniel Kahn Gillmor wrote: > > What is the best possible design we can do to make UDP flows > > be equal or better permissible across WELL BEHAVED FW and similar > > middleboxes ? Please define "WELL BEHAVED"as part of your answer. > > As i wrote to Joe, i'm not convinced that this is an answerable question > considering that no one has provided a technical argument yet for why > the enterprise firewall operators can't already do what we're talking > about here. Sorry, i need to give a multi-tiered answer: A) Lowest layer what i said initiall - mobility, load-splitting, multiplexing. B) Next layer: Yes, the FW admin could do for UDP what she does for TCP, but in todays ecosystem she will not: UDP has I) bad karma due to history of bad UDP apps in the past II) More filtering on UDP than equivalent TCP traffic because there is so much business critical TCP crap III) not a lot of business critical apps riding on UDP IV) A historic architecture view of "doing reliable transport on top of UDP is a bad, undesirable workaround" Seeded by I, II-IV form a vicious cycle. C) Decades long a ridiculously slow and cumbersome evolution of transport layer functionality. We should have done the bloody AQM work a decade or more ago. Reason IMHO is that transport layer is in the kernel, resulting in a totally broken agility model for transport layer compared to middleware/app-layer (which created . Alltogether this means to me the goal of the SPUD exercise architecturally is: Redefine the Internet architecture to say: -> Transport Layer needs to be split up into sub-layers: 1) application multiplexing layer - UDP, (running in OS) unchanged 2) common, middlebox friendly connection/packet signaling layer 3) transport connection QoE layer (reliability (FEC,ARQ), rate-control, measurement, jitter control,...) Aka: short term just existing Internet transport protocols (RTP, TCP, SCTP,...) but if one would design a new transport protocol, one could not redo whats already in 2). 2) and 3) can run in app/middleware (per app) and/or in kernel. SPUD is the first attempt at 2). If we wouldn't do 2), but just 3) over 1), we will make the chicken & egg problem of 1) even worse, because we're just asking FWs to now inspect multiple reliable transports inside UDP instead of (with 2) giving them one common single layer to inspect. And of course we also do not solve C), because there is just a bunch of things like mobility, load-splitting, per-packet marking and so on that we know we cold get from the network to benefit apps, but without moving it into user-land, it's not going to go anywhere fast. > > c) If i read it correctly, SPUD can > > > > a) set up potentially multiple independent pipes across the same 5-tuple. > > b) A single pipe can go across different 5-tuples (multipath/mobility). > > > > These two features should explain why tracking 5-tuple as you > > suggest alone would not be sufficient. > > > > Btw: I am a fan of b), i don't think a) should be encouraged given > > experience with RTCweb. In that sense, the total number of > > pipes would even be equal or smaller than the number of 5 tuples. > > This is an interesting point, thanks. I'd be curious to hear more > details about the RTCweb experience that have convinced you that (a) > should not be encouraged. Yeah, let me reword, first time around it wasn't precise: If an RTCweb session requires 10 5-tuple flows, it may take 10 times as long to set it up, and you may end up with 1/10'th maximum number of parallel sessions due to the number of NAT/FW 5-tuple pinholes you need to build. Because we want NAT/FW to be SPUD tube aware, SPUD SHOULD NOT go out and claim: "you can replace 10 5-tuple UDP flows with 1 UDP flow with 10 SPUD tubes, and your NAT/FW pinhole problem goes away". Aka: An RTCweb app worried about pinhole setup should opt for one Tube, but that in itself would already give it a lot of other benefits mobility, load-splitting, per-packet-marking,.... Btw: IMHO performance of NAT/FW pinhole setup is not a limiting factor if you just buy the right NAT/FW product, but i do by now don't think anymore that all packets of a transport level session should have the same QoS. SPUD can solve this as well with per-packet markings, and once you have that, the only reason why you would want multiple tubes for an app-session IMHO is if you explicitly want to give FWs the ability to disect your traffic (eg: drop the video portion but permit audio). > The trouble with (b), of course, is that in the multipath or mobility > case, the tube will continue its flow over different network segments, > which violates the goals people have described for open and close. > > As i move to a new path, i'm deliberately not sending a Close message > (because i want to keep the tube open, right?) -- so what do the > middleboxes do? I think the first order of business was not to be worse than TCP, but not yet trying to finalize what the most widely agreeable improvements beyond that are. > And after i've moved to a new network and want to continue the same > tube, surely i won't indicate that the flow is opening (it's already > open). As a result, the equipment on the new path won't see the Open > message -- should they discard it now? > > These arrangements seem in conflict to me. I can think of ways to improve the signaling. The main issue is the IETFs history of onpath signaling and the resulting resistance forces in the IETF against touching that subject. But consider the opportunity that redunant or cluster of NAT/FW will share SPUD tunnel-IDs amongst them to support the mobility case. No new standardized signaling required. Cheers Toerless > Regards, > > --dkg > > > P.S.: Cool domain name. Is that indicative of the role you're planning > > to take in the discussion ? ;-))) (sorry, i can never resists these questions). > > :) From nobody Wed Apr 8 20:42:44 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131A01ACF55 for ; Wed, 8 Apr 2015 20:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1B_gBazD1F5W for ; Wed, 8 Apr 2015 20:42:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565511ACF19 for ; Wed, 8 Apr 2015 20:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8402; q=dns/txt; s=iport; t=1428550959; x=1429760559; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=0IDN5j1b0ZsjptHnxo39lL7+sWIXWY0Xs7Z2UNV6IHY=; b=CRwMSrvJlZdf5Jzw4HDXaa0QTs99zZTnH6KSOC6OA1aGuqPa+rZAcrj2 wccJhJsOj3XcuLVIZKaC829qseYMKw+9xKzOShH8GjTE2JIVelPgso1Gg gicpqCcPijrQVHSVqgw9N87EDSQUUjUdyTPnmPH74a5GICQDIEBhq1l3/ M=; X-IronPort-AV: E=Sophos;i="5.11,548,1422921600"; d="scan'208";a="407240364" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 09 Apr 2015 03:42:38 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t393gcsd003342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 03:42:38 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t393ga8N004245; Wed, 8 Apr 2015 20:42:36 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t393gaK8004244; Wed, 8 Apr 2015 20:42:36 -0700 Date: Wed, 8 Apr 2015 20:42:36 -0700 From: "Toerless Eckert (eckert)" To: Jana Iyengar Message-ID: <20150409034236.GI24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <09D0D481-9380-42CA-94B1-895EC9E51428@cisco.com> <874moq2rtq.fsf@alice.fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "Joe Hildebrand \(jhildebr\)" , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 03:42:42 -0000 Jana: > It's not clear to me that we should negotiate with middlebox admins on what > bits they want -- I'd like some degree of engagement on exactly why they > want it. IMHO, and stealing a sentence from DanW: FW/Middlebox admins are charged to stop bad bits to come in (virus), stop good bits to go out (secrets) and otherwise not impact the business. Thats Mission Impossible, but there are a bunch of aspects where SPUD can help: - Filtering based on combination of port-numbers + IP addresses + roles of communicating parties (initiator, responder). This assumes you trust at least one side (because of IP) to assign port-numbers according to well known or otherwise intended use. What protocols like SPUD could help here is to substitute the limited space of 16-bit port numbers with better application-intent metadata. It could also decouple roles from sequencing of packets. Today, coming from TCP, initiator == client, responder == client, initator sends first. Now imagine you would want in IoT servers polling clients for example. By explicitly including role as a signaling element (client/server) you can do this, and e voila: UDP+SPUD becomes more flexible and FW friendly than TCP. - Filtering of "malformed"/"unknown" protocol packets. Today, for UDP everything is in some higher layer payload. So if we move an equivalent level of connection management as TCP has it into a standardized over-UDP level protocol, and will give FW operators the same degree of protection as when using TCP. - Filtering based on signalled cryptographic authenticators (eg: cert + challenge/reply snooping/filtering). Can't quite remember how much of that was proposed in SPUD, but certainly a worthwhile area for real security. Just some thoughts. There is of course a lot more. Cheers Toerless On Wed, Apr 08, 2015 at 04:46:06PM -0700, Jana Iyengar wrote: > Hi all, > > One higher-order point: This conversation seems to refer to middlebox > admins as outsiders and represents them as an ossified whole. If this new > architecture is to be a end-middle-end architecture, the middle needs to be > represented in a technical debate about the value of new protocol > machinery. I would sincerely love to see that happen. I think there's a > good bit of serious architectural work that can be done here, but this > requires wrangling with hard questions about trust, delegation, and > placement of network functions. I fear that discussions on what exact bits > to expose so that middlebox admins don't turn into fire-breathing monsters > misses the larger architectural questions. > I'm not keen to see the middlebox admin's wishlist of what headers > they'd like to see. I'm substantially more interested in understanding the > network functions they are looking for. Chances are these are implementable > without the information they think they need. If not, let's make that case > -- one network function at a time -- do a cost-benefit analysis for the > good of the Internet, and decide whether to expose any bits. > > dkg has quite nicely said many of the things I've wanted to say below; I'll > re-echo these and I'll add a couple of comments inline. > > > Yes. In talking with enterprise firewall admins, they're comfortable > > with these properties of TCP: > > > > > > - they're sure which interface the intent to start an association came > > in on > > > > This is true of UDP today. > > > +1. > > > > > > > - they're pretty sure that subsequent packets match that initial intent > > > > This is also true of UDP today; responses to the same 5-tuple (with > > source and dest swapped) provide a "pretty sure" match. > > > +1. > > > > > > > - they're pretty sure that if a box goes down comes back up, or a new > > > box takes the old one's address listening on the same port, that the > > > host will be able to reject traffic left over from an old association > > > > Surely this is a matter for endpoints and not for middleboxes, and > > dependent on the protocol implemented by the listener? For stateless > > listeners on an endpoint, they shouldn't mind seeing traffic from an old > > "association" because no state is associated with it. For stateful > > listeners, they can simply discard traffic that doesn't align with their > > internal state. > > > +1. > > > > > > > - they know when to clean up state > > > > This is untrue of either TCP or UDP today in an absolute sense. In both > > cases, they must each rely on timeouts because either peer can fall > > off-net for many different reasons that are beyond anyone's control > > > +1. > > > > > - they don't feel the need to set as aggressive timeouts as they > > > currently do for UDP, which would cause apps to send lots of extra > > > keep-alives > > > > So they're willing to permit longer timeouts for raw TCP SYNs than they > > do for UDP? That sounds like a trivial state exhaustion attack waiting > > to happen. If they treat an unacknowledged TCP SYN with an aggressive > > timeout, but then lengthen the timeout after seeing a SYN/ACK, then > > surely they can just treat an unreplied UDP 5-tuple with the aggressive > > timeout, and lengthen it when they see a response? This doesn't require > > any on-wire format change. > > > +1. I'll add that it wouldn't be surprising for clients to disappear or for > servers to drop TCP connections without sending a FIN or an RST, for a > variety of reasons. (As it turns out, this can be energy-saving for mobile > devices that don't have to wake the radio up only to receive and process a > FIN! See: http://conferences.sigcomm.org/co-next/2013/program/p211.pdf.) > > > > > From a certain perspective, it doesn't necessarily matter if we > > > completely agree with them that today's implicit heuristics are not > > > good enough. We have evidence that there are enough corporate > > > > It obviously does matter if we disagree with them. We're considering a > rework of the Internet's architecture -- I don't think this is what you're > saying, but at what point did we decide to take their needs as absolute? > "They" need to make technical arguments about their needs, if more > information is to be exposed for their use. > > > firewall admins have similar feelings, particularly in places where > > > folks that want to deploy standards-based WebRTC solutions (e.g.), > > > that I believe we need to take their perceptions into account. The > > > approach that SPUD currently takes is to smell enough like TCP from a > > > policy perspective that we can get corporate firewall admins to allow > > > the traffic by policy. > > > > Doesn't it seem silly that we will be engaging with corporate firewall > admins, but only to learn that *they think* our traffic needs to look like > TCP for them to be comfortable with it? Their perceptions of TCP are most > likely ossified, and quite possibly wrong -- what do we do then? (Perhaps > we should run the "Underhanded TCP Contest" -- make crazy stuff happen but > look like TCP on the wire :-)) TCP FastOpen and Minion both challenge prior > notions of what was (incorrectly but commonly) considered TCP behavior. I > would be quite disappointed if we were to enshrine this ossification in a > wg, and for non-TCP protocols too! This wouldn't be evolution, this would > be ossification on steroids. > > > In other words: these are potentially deployment requirements, not > > > technical requirements. > > > > This argument is also unconvincing to me. It sounds like you're saying > > that we cannot rely on this group of administrators to make reasonable > > decisions about how to operate their equipment on the basis of the data > > that they currently have, so we're going to do some unnecessary things > > to the bits on the wire that will convince them to make reasonable > > decisions on the basis of some other unnecessary data. > > > > Why should i believe that this will be the eventual outcome? A group of > > administrators has already provided evidence that they're unwilling to > > consider reasonable approaches with data format A; why would equivalent > > data format B suggest they would do anything different? > > > > +1. > > - jana From nobody Wed Apr 8 20:46:28 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCB91B2C0B for ; Wed, 8 Apr 2015 20:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 3FdYz7K-6VsX for ; Wed, 8 Apr 2015 20:46:25 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (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 CE1771B2C0A for ; Wed, 8 Apr 2015 20:46:24 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so55336370igb.1 for ; Wed, 08 Apr 2015 20:46:24 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=WTn6aVSCPSnWwxDQerq2MV1dlS3pEZpWzZnF6hDr1Kc=; b=FimqNWvdd++1+iKs3pTEg3jiMk6Ye9TgR3eOaBmgkDRm0LJV+zEPHAyfJYFoMuIyji XMHGh54sowjDOl2Qbwk/3icYvCIvKqSRn9G2St3XiVXtPaCzEW6r9WIhjAuxWCa3KLNo eSZ/Trbem1If5DQAfgMG8G93N3GEBA+1o1Y6gWFgbjzwFW5cAFnuhHDWuzhdQuIzR+Oa 1I7vppkpwYuB59bY0WJlJEibrRvH2+ZoujFEsJ0m7D6FjykU8vZ4qel6NdIGHX4MQwkQ xU8CvYGEymlSRuoILgETFumMAjMxHiU3XdtUqzeHmTn7kOBskHwuDI3no9zr311ZjCJs 1Okw== X-Gm-Message-State: ALoCoQk26nEkkCqUGzJ0ZIPshtzxkOzRiL+K1h7tyE+RNgPxyowcK+x69yHqGbnEWefR4FZjhOIh MIME-Version: 1.0 X-Received: by 10.107.128.149 with SMTP id k21mr17395589ioi.7.1428551184250; Wed, 08 Apr 2015 20:46:24 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Wed, 8 Apr 2015 20:46:24 -0700 (PDT) In-Reply-To: <20150409012229.GG24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> Date: Wed, 8 Apr 2015 20:46:24 -0700 Message-ID: From: Tom Herbert To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Daniel Kahn Gillmor , spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 03:46:27 -0000 On Wed, Apr 8, 2015 at 6:22 PM, Toerless Eckert wrote: > On Wed, Apr 08, 2015 at 06:21:21PM -0400, Daniel Kahn Gillmor wrote: >> > What is the best possible design we can do to make UDP flows >> > be equal or better permissible across WELL BEHAVED FW and similar >> > middleboxes ? Please define "WELL BEHAVED"as part of your answer. >> >> As i wrote to Joe, i'm not convinced that this is an answerable question >> considering that no one has provided a technical argument yet for why >> the enterprise firewall operators can't already do what we're talking >> about here. > > Sorry, i need to give a multi-tiered answer: > > A) Lowest layer what i said initiall - mobility, load-splitting, > multiplexing. > > B) Next layer: Yes, the FW admin could do for UDP what she does for TCP, > but in todays ecosystem she will not: > > UDP has > I) bad karma due to history of bad UDP apps in the past > II) More filtering on UDP than equivalent TCP traffic because > there is so much business critical TCP crap > III) not a lot of business critical apps riding on UDP > IV) A historic architecture view of "doing reliable transport > on top of UDP is a bad, undesirable workaround" > > Seeded by I, II-IV form a vicious cycle. > > C) Decades long a ridiculously slow and cumbersome evolution > of transport layer functionality. We should have done the bloody > AQM work a decade or more ago. > > Reason IMHO is that transport layer is in the kernel, resulting > in a totally broken agility model for transport layer > compared to middleware/app-layer (which created . > > Alltogether this means to me the goal of the SPUD exercise > architecturally is: > > Redefine the Internet architecture to say: > > -> Transport Layer needs to be split up into sub-layers: > > 1) application multiplexing layer - UDP, (running in OS) unchanged > 2) common, middlebox friendly connection/packet signaling layer > 3) transport connection QoE layer > (reliability (FEC,ARQ), rate-control, measurement, jitter control,...) > Aka: short term just existing Internet transport protocols > (RTP, TCP, SCTP,...) but if one would design a new transport > protocol, one could not redo whats already in 2). > > 2) and 3) can run in app/middleware (per app) and/or in kernel. > > SPUD is the first attempt at 2). > > If we wouldn't do 2), but just 3) over 1), we will make the > chicken & egg problem of 1) even worse, because we're just asking > FWs to now inspect multiple reliable transports inside UDP instead > of (with 2) giving them one common single layer to inspect. And > of course we also do not solve C), because there is just a bunch > of things like mobility, load-splitting, per-packet marking and so > on that we know we cold get from the network to benefit apps, but > without moving it into user-land, it's not going to go anywhere fast. > I think the kernel/user-land argument is a red herring. The problem is that middleboxes routinely participate in transport layer protocols which was never architected-- transport layer protocols are inherently end-to-end protocols. It's relatively easy to change client and server sides to accommodate new transport functionality, but pretty much impossible for us to change all the possible middleboxes in a path in a timely fashion. Just one middlebox in the path that decides to drop our packet because it doesn't understand our new option, or doesn't like our new flags can spoil everything-- it is really difficult to work around interoperabilities like this. So, yes, the net effect of this is that we have become very conservative with transport layer changes, and when we do make changes at the transport layer we often have to masquerade these in something that is considered generally palatable to middleboxes. This is why we intend to run transport protocols over UDP in the first place, and has even motivated brazen attempts to overload TCP protocol number with other things (e.g. STT). SPUD is a good opportunity to generalize and standardize middlebox/transport protocol interactions, but if the its benefits are dependent on middleboxes being updated that not is going to go anywhere fast either! >> > c) If i read it correctly, SPUD can >> > >> > a) set up potentially multiple independent pipes across the same 5-tuple. >> > b) A single pipe can go across different 5-tuples (multipath/mobility). >> > >> > These two features should explain why tracking 5-tuple as you >> > suggest alone would not be sufficient. >> > >> > Btw: I am a fan of b), i don't think a) should be encouraged given >> > experience with RTCweb. In that sense, the total number of >> > pipes would even be equal or smaller than the number of 5 tuples. >> >> This is an interesting point, thanks. I'd be curious to hear more >> details about the RTCweb experience that have convinced you that (a) >> should not be encouraged. > > Yeah, let me reword, first time around it wasn't precise: > > If an RTCweb session requires 10 5-tuple flows, it may take > 10 times as long to set it up, and you may end up with 1/10'th maximum > number of parallel sessions due to the number of NAT/FW 5-tuple pinholes > you need to build. Because we want NAT/FW to be SPUD tube aware, > SPUD SHOULD NOT go out and claim: > > "you can replace 10 5-tuple UDP flows with 1 UDP flow with 10 SPUD tubes, > and your NAT/FW pinhole problem goes away". > > Aka: An RTCweb app worried about pinhole setup should opt for one > Tube, but that in itself would already give it a lot of other benefits > mobility, load-splitting, per-packet-marking,.... > > Btw: IMHO performance of NAT/FW pinhole setup is not a limiting factor > if you just buy the right NAT/FW product, but i do by now don't > think anymore that all packets of a transport level session should > have the same QoS. > > SPUD can solve this as well with per-packet markings, and > once you have that, the only reason why you would want multiple > tubes for an app-session IMHO is if you explicitly want to give > FWs the ability to disect your traffic (eg: drop the video portion > but permit audio). > >> The trouble with (b), of course, is that in the multipath or mobility >> case, the tube will continue its flow over different network segments, >> which violates the goals people have described for open and close. >> >> As i move to a new path, i'm deliberately not sending a Close message >> (because i want to keep the tube open, right?) -- so what do the >> middleboxes do? > > I think the first order of business was not to be worse than TCP, > but not yet trying to finalize what the most widely agreeable improvements > beyond that are. > >> And after i've moved to a new network and want to continue the same >> tube, surely i won't indicate that the flow is opening (it's already >> open). As a result, the equipment on the new path won't see the Open >> message -- should they discard it now? >> >> These arrangements seem in conflict to me. > > I can think of ways to improve the signaling. The main > issue is the IETFs history of onpath signaling and the resulting > resistance forces in the IETF against touching that subject. > > But consider the opportunity that redunant or cluster of > NAT/FW will share SPUD tunnel-IDs amongst them to support > the mobility case. No new standardized signaling required. > > Cheers > Toerless > >> Regards, >> >> --dkg >> >> > P.S.: Cool domain name. Is that indicative of the role you're planning >> > to take in the discussion ? ;-))) (sorry, i can never resists these questions). >> >> :) > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Wed Apr 8 21:15:12 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2049B1B2C65 for ; Wed, 8 Apr 2015 21:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 AkdlNOqL-EzU for ; Wed, 8 Apr 2015 21:15:09 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0691B2C67 for ; Wed, 8 Apr 2015 21:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2355; q=dns/txt; s=iport; t=1428552909; x=1429762509; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=M6q4hdN5dRX3sDlEAZ1NXPtwhVAj36SNP1pHKiOh2KM=; b=jdyiEaT/YjzeEcoRoDuL6VYM8Qs8ox5BFI4OSKyJW0sYzHNkFCkKMDV+ AnogIS6uZON7aeVeLK8Cby0A28gnuoQpeOzMGZJMDgswEa7tNvQUa+OHD M3eql+6PKkdSJoMGnAxFDm0vYdUA6A7fkVsj8ZiTbvQRkkLtpfoLvIgqB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BQCo+yVV/5BdJa1cgwjFTIdPAoEyOhIBAQEBAQEBfYQfAQEBAwE6PwULCxgJJQ8FSYg1CMx1AQEBAQEBAQEBAQEBAQEBAQEBAQEYiyuEMUsHhC0FiyeLLYQmAYEdgzeJBIcDIoQPHoJ0AQEB X-IronPort-AV: E=Sophos;i="5.11,548,1422921600"; d="scan'208";a="139514019" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP; 09 Apr 2015 04:15:08 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t394F8QQ016513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 04:15:08 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t394F74S006452; Wed, 8 Apr 2015 21:15:07 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t394F7Yc006451; Wed, 8 Apr 2015 21:15:07 -0700 Date: Wed, 8 Apr 2015 21:15:07 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20150409041507.GJ24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Daniel Kahn Gillmor , spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 04:15:11 -0000 On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote: > I think the kernel/user-land argument is a red herring. Elaborate please. To me its probably the biggest motivator for SPUD. Otherwise we could design all we need into IP and TCP. > The problem is > that middleboxes routinely participate in transport layer protocols > which was never architected-- transport layer protocols are inherently > end-to-end protocols. Thats 1970'th IETF katechism. I would call middleboxes a big contributor to todays success of Internet technologies. > It's relatively easy to change client and > server sides to accommodate new transport functionality, Which is why we have OS-level TCP functions that lag state of the art on average by a decade. > but pretty much impossible for us to change all the possible middleboxes > in a path in a timely fashion. Just one middlebox in the path that decides > to drop our packet because it doesn't understand our new option, or > doesn't like our new flags can spoil everything-- it is really > difficult to work around interoperabilities like this. Everybody and their dog concerned about this problem is already automatically falling back to IP over SSL on port 443. We simply need to do the best to evolve away from that. Thats why it is important to offer benefits to those middleboxes. > So, yes, the > net effect of this is that we have become very conservative with > transport layer changes, and when we do make changes at the transport > layer we often have to masquerade these in something that is > considered generally palatable to middleboxes. This is why we intend > to run transport protocols over UDP in the first place, and has even > motivated brazen attempts to overload TCP protocol number with other > things (e.g. STT). SPUD is a good opportunity to generalize and > standardize middlebox/transport protocol interactions, but if the its > benefits are dependent on middleboxes being updated that not is going > to go anywhere fast either! Any firewall can start out processing SPUD just as UDP and once FW firmware improves it will simply improve from there. Nobody says firewalls MUST update, we just say that we want to provide at least the same toolset for relevant inspection firewalls as what TCP gives them. Cheers Toerless From nobody Wed Apr 8 22:20:51 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41291B2BCB for ; Wed, 8 Apr 2015 22:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 ELEr-TcRZpXx for ; Wed, 8 Apr 2015 22:20:48 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (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 C6FA21B2BC9 for ; Wed, 8 Apr 2015 22:20:48 -0700 (PDT) Received: by igblo3 with SMTP id lo3so56441072igb.0 for ; Wed, 08 Apr 2015 22:20:48 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=hznEYWfxaSjyvDr7vrhyTV/as8NyF4ehSs9HRbpZSxQ=; b=Y71UVTe5BCE3ikpiPZjy3ZfJoEd2mWqkvyuKJ50wEATC4oEpv5krxcX0s3lwHReZS6 RUZtCWWQhBbvfTt/ul2QJqRKrUjbYio+28wDcJrWpQJDVXGxgOC3dKcJ1kq4QYJRrZGf w6N5LPBxX2xOqQavzDF8Gt5NSyT4H2iUBHRHC5czus9dBb1jWWFFOiEXWtqoTAcn+NzE uahyPU+VWwur+cjSI4Mij8YdPLsk48GH6RAAP8USuhDGLVdf08NO+LrD8fLF+7uKlNq4 N6hwlypJKeS8dsPLcuwFXDeWAyc4MYLZ172v4ih5cR3o3yEhyes3JNvz+0KzbbSpayUn dtvg== X-Gm-Message-State: ALoCoQm+E++o3VyXerEbo3NtPW3fl8vG9u9JS883TwOqbtBF+65F0RIRQm2LuTgAriuDOZVRHC/Y MIME-Version: 1.0 X-Received: by 10.42.236.78 with SMTP id kj14mr29004233icb.43.1428556848167; Wed, 08 Apr 2015 22:20:48 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Wed, 8 Apr 2015 22:20:48 -0700 (PDT) In-Reply-To: <20150409041507.GJ24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> Date: Wed, 8 Apr 2015 22:20:48 -0700 Message-ID: From: Tom Herbert To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Daniel Kahn Gillmor , spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 05:20:50 -0000 On Wed, Apr 8, 2015 at 9:15 PM, Toerless Eckert wrote: > On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote: >> I think the kernel/user-land argument is a red herring. > > Elaborate please. To me its probably the biggest motivator for > SPUD. Otherwise we could design all we need into IP and TCP. > >> The problem is >> that middleboxes routinely participate in transport layer protocols >> which was never architected-- transport layer protocols are inherently >> end-to-end protocols. > > Thats 1970'th IETF katechism. I would call middleboxes a big contributor > to todays success of Internet technologies. > Maybe, but the consequences of diverging from the end-to-end model is reality we still need to deal with. When we deploy transport protocols at scale on the Internet we are still bound in a large part by the least common denominator network devices out there. There are deployed devices that choke on our attempts to extend transports. We need to be concerned about these, we simply can't completely break connectivity for 1% of the world in order to give everyone else a 5% performance improvement. >> It's relatively easy to change client and >> server sides to accommodate new transport functionality, > > Which is why we have OS-level TCP functions that lag state of the art > on average by a decade. > I can't comment on other OSes, but I will say that the rate of change to TCP and transport layer protocols in Linux and high and significantly outpaces IETF standards (e.g. IW=10, lowering initRTO, CC changes). These arguments seem to have more to do with the time for deployment. This is not a problem with any reasonably modern OS, but people are still concerned with getting changes into legacy deployments (Windows is often cited). But, if you have specific OS features that you think are missing I'd be happy discuss that off-thread. >> but pretty much impossible for us to change all the possible middleboxes >> in a path in a timely fashion. Just one middlebox in the path that decides >> to drop our packet because it doesn't understand our new option, or >> doesn't like our new flags can spoil everything-- it is really >> difficult to work around interoperabilities like this. > > Everybody and their dog concerned about this problem is already > automatically falling back to IP over SSL on port 443. We simply need to > do the best to evolve away from that. Thats why it is important to offer > benefits to those middleboxes. > This a general problem with modifying transport protocols. For instance, it's potential problems with middleboxes that may wreak havoc with attempts to increase the TCP option space (EDO). >> So, yes, the >> net effect of this is that we have become very conservative with >> transport layer changes, and when we do make changes at the transport >> layer we often have to masquerade these in something that is >> considered generally palatable to middleboxes. This is why we intend >> to run transport protocols over UDP in the first place, and has even >> motivated brazen attempts to overload TCP protocol number with other >> things (e.g. STT). SPUD is a good opportunity to generalize and >> standardize middlebox/transport protocol interactions, but if the its >> benefits are dependent on middleboxes being updated that not is going >> to go anywhere fast either! > > Any firewall can start out processing SPUD just as UDP and once > FW firmware improves it will simply improve from there. Nobody > says firewalls MUST update, we just say that we want to provide > at least the same toolset for relevant inspection firewalls as what TCP gives > them. It's pretty clear that for the foreseeable future were pretty much stuck with using either TCP or UDP on the Internet (barring that something like SCTP would ever get traction). Since we can't do reasonably stateful firewalls or stateful NAT with UDP that is a fundamental problem which constrains us to use TCP. There are needs for new transport protocols, so encapsulating them in UDP seems to be pragmatic approach, but we really need the ability for middlesboxes to track state for such things-- this is what I hope SPUD provides. Tom > > Cheers > Toerless From nobody Wed Apr 8 23:22:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1DD1B2D0F for ; Wed, 8 Apr 2015 23:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 v_Ha-na80zpz for ; Wed, 8 Apr 2015 23:22:22 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9AC1B2CD6 for ; Wed, 8 Apr 2015 23:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7440; q=dns/txt; s=iport; t=1428560542; x=1429770142; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=7F7Ddvk3nEPNPhuV2nKS5gbRWKU1ePaVjnRZIJumRqo=; b=LvTiEoMjEf9Ms6aB0xty3CrW5gRb93FTXpPtLh0NLD+STRXLgpIECOFp HJJ20w0pPPz368zlslzvtDFNdfAK9FgvqZfl1KJfrtbmbk26x5kmREKwM MduY+Y2YVbkRvzrF6uwwajlS7Shad97uw7cd75M5F/8ZmfWq2aO0e9160 c=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmBAAEGiZV/xbLJq1ch0vJAQKBcBEBAQEBAQEBfYQfAQEBAwEjVQYLCxgJFgsCAgkDAgECAUUGAQwIAQGIHgi2BJZZAQEBAQEBAQMBAQEBAQEBARqLK4QtVoJogUUBBIYejESBM4ZmhxaNRSKDcTyBMweBOgEBAQ X-IronPort-AV: E=Sophos;i="5.11,548,1422921600"; d="asc'?scan'208,217";a="422860391" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Apr 2015 06:22:18 +0000 Received: from [10.61.95.48] (ams3-vpn-dhcp7985.cisco.com [10.61.95.48]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t396MIET020237; Thu, 9 Apr 2015 06:22:18 GMT Message-ID: <55261A99.5090801@cisco.com> Date: Thu, 09 Apr 2015 08:22:17 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , spud@ietf.org References: <87iod631nv.fsf@alice.fifthhorseman.net> In-Reply-To: <87iod631nv.fsf@alice.fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MtNg2mJvNHnL476uQl9kmITbOf9qa5J7k" Archived-At: Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 06:22:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MtNg2mJvNHnL476uQl9kmITbOf9qa5J7k Content-Type: multipart/alternative; boundary="------------040402000408020006040303" This is a multi-part message in MIME format. --------------040402000408020006040303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel, On 4/8/15 8:39 PM, Daniel Kahn Gillmor wrote: > Open is superfluous > ------------------- > > Given the existing 5-tuple, on-path equipment trivially knows when a > flow starts already: it is a 5-tuple that they haven't seen before. If= > you want to maintain a distinction between a one-side-opened flow and a= > replied flow, this is also traceable by looking at the 5-tuple. It's > not clear that the "open" signal gives on-path equipment any additional= > useful information that it didn't have already from the 5-tuple. Open provides an indication that the flow is not a continuation, that new state should be instantiated, that any old state of the 5-tuple should be discarded. Opens may flow in either direction, but may be authorized for only some uses. > > Close is unreliable > ------------------- > > One of the reasons on-path equipment would like a "close" signal is so > that they know when to tear down associations that are no longer needed= =2E > This would reduce memory consumption and make a device more resilient t= o > DoS attacks that exhaust its connection table. Without "close", the > on-path equipment has to rely on timers to decide when to tear down the= > connection. > > Unfortunately, we can't rely on endpoints to send Close. Legitimate > endpoints crash, run out of power, or have their network connectivity > cut. This is by far the exception and not the rule. Most state is torn down. > So on-path equipment needs to maintain timers anyway if they're > tracking flow state instead of just passing IP traffic statelessly. This misses the point. If there is an implicit understanding of the behavior of the endpoints, firewalls needn't keep state. It is sufficient in many cases to know that SYNs should be blocked whereas SYN|ACK should be passed. No state retained on the firewall. There is no equivalent in UDP without going up the stack. Moreover, if a firewall is tracking state, it cannot tell if an incoming packet is a continuation of a or an initiation if it is *not* using timers. This makes both open and close (as well as perhaps some other gunk) very useful. > And > in a DoS scenario, it's trival for an actively malicious end-point to > send lots of "open" messages without ever sending a "close", so it > doesn't protect against DoS either. In fact, this is precisely the nature of a SYN attack. Firewalls regularly detect and block them in TCP. UDP requires much more effort and understanding of the higher layers. Eliot --------------040402000408020006040303 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel,


On 4/8/15 8:39 PM, Daniel Kahn Gillmor= wrote:
Open is superfluous
-------------------

Given the existing 5-tuple, on-path equipment trivially knows when a
flow starts already: it is a 5-tuple that they haven't seen before.  If
you want to maintain a distinction between a one-side-opened flow and a
replied flow, this is also traceable by looking at the 5-tuple.  It's
not clear that the "open" signal gives on-path equipment any additional
useful information that it didn't have already from the 5-tuple.
Open provides an indication that the flow is not a continuation, that new state should be instantiated, that any old state of the 5-tuple should be discarded.=C2=A0 Opens may flow in either direction= , but may be authorized for only some uses.

Close is unreliable
-------------------

One of the reasons on-path equipment would like a "close" signal is so
that they know when to tear down associations that are no longer needed.
This would reduce memory consumption and make a device more resilient to
DoS attacks that exhaust its connection table.  Without "close", the
on-path equipment has to rely on timers to decide when to tear down the
connection.

Unfortunately, we can't rely on endpoints to send Close.  Legitimate
endpoints crash, run out of power, or have their network connectivity
cut.

This is by far the exception and not the rule.=C2=A0 Most state is to= rn down.

  So on-path equipment needs to maintain timers anyw=
ay if they're
tracking flow state instead of just passing IP traffic statelessly.
=

This misses the point.=C2=A0 If there is an implicit understanding of= the behavior of the endpoints, firewalls needn't keep state.=C2=A0 It is sufficient in many cases to know that SYNs should be blocked whereas SYN|ACK should be passed.=C2=A0 No state retained on the firewall.=C2= =A0 There is no equivalent in UDP without going up the stack.

Moreover, if a firewall is tracking state, it cannot tell if an incoming packet is a continuation of a <flow/spud/tube> or an initiation if it is not using timers.=C2=A0 This makes both op= en and close (as well as perhaps some other gunk) very useful.

  And
in a DoS scenario, it's trival for an actively malicious end-point to
send lots of "open" messages without ever sending a "close", so it
doesn't protect against DoS either.

In fact, this is precisely the nature of a SYN attack.=C2=A0 Firewall= s regularly detect and block them in TCP.=C2=A0 UDP requires much more effort and understanding of the higher layers.

Eliot
--------------040402000408020006040303-- --MtNg2mJvNHnL476uQl9kmITbOf9qa5J7k 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 iQEcBAEBCAAGBQJVJhqaAAoJEIe2a0bZ0nozf9YH+gOVWjb3acnTT8VUzDDQuCSQ UpI2grNMshlFVEppsgj34yp0nbVXI9zmuiWzowAxv3S7cEydZeoB/oF41xK4SwjD MMO1/ebQG20deHacSZLXJg3EHwMNfu0zYPcUbBmUmXxfjp9c6yuajoYishQaQiMB 8M7Jn+2toinx82Q7VfvzoxjAZU8vnxDaj4K0d0Q6dZwFl3/C67dOzftZp1guiARD ljkTgJVomcFqRY/Ro6yB0m045/KuOYealVK5El8jNNlDrSIHcuflWwsahaz085d6 rscf6lLLZE7bQ0EQxSi71mYmM9r2g6Aaiwi8IYtqFoOiu6nJTiNvN5yq39C45uY= =Yi27 -----END PGP SIGNATURE----- --MtNg2mJvNHnL476uQl9kmITbOf9qa5J7k-- From nobody Thu Apr 9 06:09:23 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF41B2D38 for ; Thu, 9 Apr 2015 06:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 bgWi3_ss_C8O for ; Thu, 9 Apr 2015 06:09:20 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 7BC1A1B2D3A for ; Thu, 9 Apr 2015 06:09:19 -0700 (PDT) Received: by laat2 with SMTP id t2so81955241laa.1 for ; Thu, 09 Apr 2015 06:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4PtZNS6aeSJAMwNzMhVsGvlXsYjXhJcc9E+/sJTsXwo=; b=seLxLOE3vBUtfGWevPmqQz7Cqqf/++Mzh+D6bfvBpWvVshiXVpL0wG7F8lC3+SScL6 F2q4HA3qI+2PKPelRSVertwMPE0tPWg9wRIdhyVN5bcepnXl7xhHgub9lbnPhMA+IwU5 /Gl1Zbaozz4pYWnm1qha3EOfwKpnB1OhHodEQlare0xYX5WQb++oIR+1Mn041aDmXr0v ElxYtZULoynAPAtWwAsrTquE6eqc2MPLc+Zs4RZ2pLOXVt4HI2BuFp52gF5srh9HKpFT 7nN95nDWPemCqIr2+XmEf5nmpw5ewNcI1UEciPiNKr/V2/Uoms/m/Js67+Gs9zS5HVdQ LpLg== MIME-Version: 1.0 X-Received: by 10.152.6.1 with SMTP id w1mr4506756law.91.1428584958042; Thu, 09 Apr 2015 06:09:18 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Thu, 9 Apr 2015 06:09:17 -0700 (PDT) In-Reply-To: <20150409041507.GJ24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> Date: Thu, 9 Apr 2015 09:09:17 -0400 X-Google-Sender-Auth: wWSoYTh_r8TQGy3Srte_q5wcwr0 Message-ID: From: Phillip Hallam-Baker To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tom Herbert , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:09:22 -0000 On Thu, Apr 9, 2015 at 12:15 AM, Toerless Eckert wrote: > On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote: >> I think the kernel/user-land argument is a red herring. > > Elaborate please. To me its probably the biggest motivator for > SPUD. Otherwise we could design all we need into IP and TCP. TCP should probably not happen in the kernel either. Nor should printer drivers be in the kernel or anything that does not require the intermediation of the security monitor. Looking at the shoot-yourself-in-the-foot opportunities in the IPv6 encoding, I am not exactly anxious to put all those untrusted code paths in a position where they can root the machine. One of the main reasons the current generation of O/S are chronically insecure is that 90% of the stuff that is inside the security perimeter has no business being there. At this point TCP is water under the bridge. But that does not mean we are obliged to remake the mistake. When TCP was designed, the mantra was 'everything is a stream'. That was the right abstraction for Telnet and FTP and Mail. It is probably not the right abstraction for real time web where an unreliable sequence of chunks seems a better fit. From nobody Thu Apr 9 06:19:35 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC19C1A0BE8 for ; Thu, 9 Apr 2015 06:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 rVibWFKpngbe for ; Thu, 9 Apr 2015 06:19:31 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 1262D1A0AF8 for ; Thu, 9 Apr 2015 06:18:41 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1YgCLv-0000t7-E5; Thu, 09 Apr 2015 15:18:39 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 35D71B00532; Thu, 9 Apr 2015 15:18:39 +0200 (CEST) Message-ID: <55267C2F.7060303@kit.edu> Date: Thu, 09 Apr 2015 15:18:39 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Brian Trammell , Daniel Kahn Gillmor References: <87iod631nv.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1428585519. Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:19:34 -0000 Hi Brian, On 09.04.2015 at 00:03 Brian Trammell wrote: > SPUD's ACK (roughly TCP SYN/ACK) is more interesting. A SYN/ACK in > proper response to a SYN means that someone on the other side of > the firewall decided a connection could proceed, or more mundanely > means there is now actually state on the endpoint so any state the > network needs should be there too. For bidirectional transports > (i.e., for Interesting thought, but only for the very simple TCP model the endpoint already created state and is thus vulnerable to TCP SYN flood attacks. So a responding endpoint is probably not a sufficient indication...see also below. > every transport one should be running over SPUD, since congestion > control requires feedback, as does proof of reverse reachability > to reduce spoofing) it might be that ACK is sufficient to get us > what we need. (In reviewing that paragraph, we probably also need > to name it something other than ACK.) SYN Flooding would also result in endpoints responding, i.e., the SYN/ACK is IMHO not a sufficient indication for a proper conversation/state setup as the third way (ACK) would probably be. Moreover, purely unidirectional data flows (e.g., very sparse measurement data) may have no such prior handshake, or multicast flows may have no ACKs. > some sort of heuristic for rate-limiting. Indeed, these all speak > toward making ACK the important OPEN. Maybe, but that is still not sufficient IMHO. Regards, Roland From nobody Thu Apr 9 06:55:19 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490C01A1ADF for ; Thu, 9 Apr 2015 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 viMFcxfrJ6FL for ; Thu, 9 Apr 2015 06:55:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050F91A1A88 for ; Thu, 9 Apr 2015 06:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1961; q=dns/txt; s=iport; t=1428587712; x=1429797312; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=EdrfZzeiDbmEvhmDdoXV1qeehEfj+yLsEMpecQ+zen8=; b=dwMGrmrWcda+Tq6HiWCerN6Racr5hExhjXvpTIHGNaBASMC5OKca+zBZ H91uweimIpgJ1ersaFaSxKXDCzZoxjqzD+BXKKXFC+W+H4F5aICLPnROL EJk2n+c2ClqFCO4bLBh/3duRpa+8AgdxVHxTeUFNOgEVFQzKOoPTr9knY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHBQC+gyZV/5pdJa1cgwjNSQKBPkwBAQEBAQF+hB8BAQEDATo/BQsLGAklDwVJiDUIzWIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyuEKgEBUAeELQWLJ49dAZRlIoQPHoE8gTgBAQE X-IronPort-AV: E=Sophos;i="5.11,550,1422921600"; d="scan'208";a="407353466" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 09 Apr 2015 13:55:11 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t39DtAqA004897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 13:55:11 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t39DtAIu010568; Thu, 9 Apr 2015 06:55:10 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t39Dt9mh010567; Thu, 9 Apr 2015 06:55:09 -0700 Date: Thu, 9 Apr 2015 06:55:09 -0700 From: Toerless Eckert To: Phillip Hallam-Baker Message-ID: <20150409135509.GK24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:55:17 -0000 On Thu, Apr 09, 2015 at 09:09:17AM -0400, Phillip Hallam-Baker wrote: > TCP should probably not happen in the kernel either. Nor should > printer drivers be in the kernel or anything that does not require the > intermediation of the security monitor. Right. As an OS person i would love for someone to implement a "raw transport socket" option for unprivileged processes. Implement in linux, go to POSIX, spend a decade trying to get it proliferated across OSs. Alas, as a network person, i think this would be an exercise in futility because the only real benefit would be to create connections between a legacy kernel TCP stack and a new userland TCP stack and those connections would likely be mostly have little benefits over a simple old kernel to old kernel TCP stack: If you want new functionalities, most of the time, both sides need to support these, the fastest way to get both sides to support them is to both run them in userland over UDP and once people get their minds around the fact that this is good and not just a workaround, the interest in "native TCP" for new improved transport functions should recede. > Looking at the shoot-yourself-in-the-foot opportunities in the IPv6 > encoding, I am not exactly anxious to put all those untrusted code > paths in a position where they can root the machine. > > One of the main reasons the current generation of O/S are chronically > insecure is that 90% of the stuff that is inside the security > perimeter has no business being there. > > At this point TCP is water under the bridge. But that does not mean we > are obliged to remake the mistake. > > When TCP was designed, the mantra was 'everything is a stream'. That > was the right abstraction for Telnet and FTP and Mail. It is probably > not the right abstraction for real time web where an unreliable > sequence of chunks seems a better fit. What's missing from SCTP ? Cheers Toerless From nobody Thu Apr 9 07:09:36 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8A1A1B29 for ; Thu, 9 Apr 2015 07:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 U0R3I6mMEHkl for ; Thu, 9 Apr 2015 07:09:34 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 85F4D1A02F1 for ; Thu, 9 Apr 2015 07:09:34 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so83307636lbb.3 for ; Thu, 09 Apr 2015 07:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5jXvHKXaPwxjieIfN/br9UZTdTPEprcl/hgZvxFps7Y=; b=wAg2yB9pLTns8fpkGkLXEyT7rQUFqcxA8jTWIuSAzYvJeejAF1DoNcHgj1D+L6W/mC GfN8Gn173wWnS0eafz7jVexZcfMz3mVRKnVa/cmtvcwa3hThxpYJs9Y8ZVcktfg4+5yi 7FGLQgL4jyUdxioy3BvFFd7cZp5K2MOhVJ9tZNu8NnFcY3gd+kz8wmu7A8GUnqFVVJK7 FvJPuXZtlxxgdaNW0xxf6TgvF426BivgofFK+lp/y/3NvussDTaRnxPwqa0RSRoIrvWv u/SP3Hesi6F02Qg4x2wIX/RBDbC20FH8g7V9FhFJci4pzD91/Z1+j665UqOs6rZgZVAy fSpw== MIME-Version: 1.0 X-Received: by 10.112.42.233 with SMTP id r9mr28896996lbl.58.1428588573024; Thu, 09 Apr 2015 07:09:33 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Thu, 9 Apr 2015 07:09:32 -0700 (PDT) In-Reply-To: <20150409135509.GK24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409135509.GK24286@cisco.com> Date: Thu, 9 Apr 2015 10:09:32 -0400 X-Google-Sender-Auth: 3X_O7RXN9estgskgyA-6RcRovYk Message-ID: From: Phillip Hallam-Baker To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tom Herbert , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:09:36 -0000 On Thu, Apr 9, 2015 at 9:55 AM, Toerless Eckert wrote: > On Thu, Apr 09, 2015 at 09:09:17AM -0400, Phillip Hallam-Baker wrote: >> TCP should probably not happen in the kernel either. Nor should >> printer drivers be in the kernel or anything that does not require the >> intermediation of the security monitor. > > Right. As an OS person i would love for someone to implement a > "raw transport socket" option for unprivileged processes. Implement > in linux, go to POSIX, spend a decade trying to get it proliferated across > OSs. Yep > Alas, as a network person, i think this would be an exercise in futility > because the only real benefit would be to create connections between > a legacy kernel TCP stack and a new userland TCP stack and those > connections would likely be mostly have little benefits over a simple > old kernel to old kernel TCP stack: As I said, water under the bridge. We are now constrained by what legacy implementations provide. > If you want new functionalities, most of the time, both sides need to support > these, the fastest way to get both sides to support them is to both > run them in userland over UDP and once people get their minds around > the fact that this is good and not just a workaround, the interest in > "native TCP" for new improved transport functions should recede. The current trend is actually in the opposite direction. On Windows the HTTP server is an O/S resource and user mode processes bind to specific URL paths. This allows different Web services to be implemented in completely separate processes. >> When TCP was designed, the mantra was 'everything is a stream'. That >> was the right abstraction for Telnet and FTP and Mail. It is probably >> not the right abstraction for real time web where an unreliable >> sequence of chunks seems a better fit. > > What's missing from SCTP ? Quite, do we have the opportunity for a quick fix here? If SCTP has already done all the necessary design work, can we just bolt that on top of UDP in place of IP and declare a quick victory? Worth a look to see... From nobody Thu Apr 9 07:21:41 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFC01A6F1E for ; Thu, 9 Apr 2015 07:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 5LxxkHzS3Ub6 for ; Thu, 9 Apr 2015 07:21:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272CF1A6F17 for ; Thu, 9 Apr 2015 07:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1000; q=dns/txt; s=iport; t=1428589292; x=1429798892; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Xw/dTNQG8Jz0rYhcuqiIWWN/VBsp/lDhopA399Aa/8k=; b=g3Mn23g8ZYpXQz6hbh64GyYnyEvuJRn5tt4pn946phma48YyrLJsNC6u 6fgtIE5mDRTkPfu+lBpmmlpt9AH1PWoq7w+P80PhMMnInd7ML/zbu2W3K Ug8JRFcsQfWr7WjmdOxYUyh176EqSP0iZF/ko3CmKBmRuguJOQz5Izu/S M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BMBACgiiZV/5JdJa1cgwhSxR4Jh1ACgT44FAEBAQEBAQF9hB8BAQEDATo/EAsYCSUPBUkuiAcIzVgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyuEMUsHhC0BBIsnj10BgR2GH40pIoQPHoJ0AQEB X-IronPort-AV: E=Sophos;i="5.11,550,1422921600"; d="scan'208";a="139680730" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 09 Apr 2015 14:21:31 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t39ELU7m013650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 14:21:31 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t39ELUoV012247; Thu, 9 Apr 2015 07:21:30 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t39ELT4d012246; Thu, 9 Apr 2015 07:21:29 -0700 Date: Thu, 9 Apr 2015 07:21:29 -0700 From: Toerless Eckert To: Phillip Hallam-Baker Message-ID: <20150409142129.GM24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409135509.GK24286@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:21:39 -0000 On Thu, Apr 09, 2015 at 10:09:32AM -0400, Phillip Hallam-Baker wrote: > The current trend is actually in the opposite direction. On Windows > the HTTP server is an O/S resource and user mode processes bind to > specific URL paths. This allows different Web services to be > implemented in completely separate processes. But sharing the same transport stack ;-) > > What's missing from SCTP ? > > Quite, do we have the opportunity for a quick fix here? If SCTP has > already done all the necessary design work, can we just bolt that on > top of UDP in place of IP and declare a quick victory? You should talk to the SCTP folks or read the specs. I am not on top of the details but i think it does a lot of what you ask. For me, userland eg: SCTP would be a pre-requisite to make a solution like SPUD successful, not an argument to not do SPOD. See my mail where i was trying to explain the three layers of the transport stack as i would like to see it. Cheers Toerless From nobody Thu Apr 9 07:27:23 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D4D1A6F33 for ; Thu, 9 Apr 2015 07:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4g54cTrYa2KR for ; Thu, 9 Apr 2015 07:27:09 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 39B2B1A1BCF for ; Thu, 9 Apr 2015 07:27:09 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 76D0A1A0111; Thu, 9 Apr 2015 16:27:08 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FA2BC258-6A84-4A97-9D6E-4C56D5806641"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: Date: Thu, 9 Apr 2015 16:27:07 +0200 Message-Id: References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409135509.GK24286@cisco.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Tom Herbert , Toerless Eckert , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:27:13 -0000 --Apple-Mail=_FA2BC258-6A84-4A97-9D6E-4C56D5806641 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 09 Apr 2015, at 16:09, Phillip Hallam-Baker = wrote: >=20 >>> When TCP was designed, the mantra was 'everything is a stream'. That >>> was the right abstraction for Telnet and FTP and Mail. It is = probably >>> not the right abstraction for real time web where an unreliable >>> sequence of chunks seems a better fit. >>=20 >> What's missing from SCTP ? >=20 > Quite, do we have the opportunity for a quick fix here? If SCTP has > already done all the necessary design work, can we just bolt that on > top of UDP in place of IP and declare a quick victory? >=20 > Worth a look to see... RFC 6951, though it uses a single well-known port for all encapsulated = SCTP so is less suitable for userland implementations. You can stick = DTLS on top of SCTP (RFC 6083) if you're okay exposing the transport = headers, or SCTP on top of DTLS as in WebRTC data channels if not. Cheers, Brian --Apple-Mail=_FA2BC258-6A84-4A97-9D6E-4C56D5806641 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 iQEcBAEBCgAGBQJVJow8AAoJENt3nsOmbNJcrnwH/ip43ByxYB/GyurPDowRr3F4 JgWuq3YUbnyZFNi9EavgDE5NC5HtPoo8yid/SN7rdkUuD5N6PdJAr7FYztjX2N95 ycURzxJxI6kgStcAdOAWGtM4nGJ4VGY9qEW6wYY0P118IB0+OClFiGFRKaE9Kkmx 0mMksyvZRDglBQYzgRuq7rT5+09htCwyVJgy+vxrZJ8HWmMEJa7ZelTW4cFO8wUJ 7rvOrey5tis1klSqqfMM/8a0VsVZnmTsIIFerGI5eeuo11+oYCi7I4oIVnocwMV0 jM6qJMJ0fA3cR9P/gOuSMjl/abaY1xowLp7188EtZgH0MeHVe/d/hNQ3mABm1Zs= =H0BJ -----END PGP SIGNATURE----- --Apple-Mail=_FA2BC258-6A84-4A97-9D6E-4C56D5806641-- From nobody Thu Apr 9 07:29:47 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7E71A6F34 for ; Thu, 9 Apr 2015 07:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 DOaiJHAdAPMA for ; Thu, 9 Apr 2015 07:29:44 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FC21A7030 for ; Thu, 9 Apr 2015 07:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1329; q=dns/txt; s=iport; t=1428589776; x=1429799376; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=n/P4HcjV5ivTOZBXwVKEmVGO1aI30dmRICqBArD8050=; b=KE760rFsulULqLKGUiviPfK71G2TmJryNriomNG55I3fwOHdEuykF23J GIxg14O9LgasEMYmiMCPpmujuPcdodFMtY5sRaPw7kpMmNQIeFOyJ/nZs zUgNLDTi2CXMbmEt7680EHYt4qQxjeYdgAtZ1EwhLKWWUx7+d16vLx+i3 k=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.11,550,1422921600"; d="asc'?scan'208";a="423426802" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Apr 2015 14:29:34 +0000 Received: from [10.61.95.48] (ams3-vpn-dhcp7985.cisco.com [10.61.95.48]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t39ETXiL029559; Thu, 9 Apr 2015 14:29:34 GMT Message-ID: <55268CCD.7080904@cisco.com> Date: Thu, 09 Apr 2015 16:29:33 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Brian Trammell , Phillip Hallam-Baker References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409135509.GK24286@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GwTwwm4KOCuuvc0xw87Sg2Dghq7vfOjTJ" Archived-At: Cc: Tom Herbert , Toerless Eckert , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:29:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GwTwwm4KOCuuvc0xw87Sg2Dghq7vfOjTJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/9/15 4:27 PM, Brian Trammell wrote: > > RFC 6951, though it uses a single well-known port for all encapsulated = SCTP so is less suitable for userland implementations. You can stick DTLS= on top of SCTP (RFC 6083) if you're okay exposing the transport headers,= or SCTP on top of DTLS as in WebRTC data channels if not. Meh. If inetd could do it for TCP services... Eliot --GwTwwm4KOCuuvc0xw87Sg2Dghq7vfOjTJ 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 iQEcBAEBCAAGBQJVJozNAAoJEIe2a0bZ0nozaugH/j91NBL4h44KL67l8rIrbegK J/eCexZJJM5/e725vwg/hc8ZrOnXDZ1K9cLxB4U4PHoUEaLg0wkh5CQfXQjHx+UW NrJXcmGpQ/1iRN6uvMh7q97d5xOGIOPu3Z4mg/feYl3/6bqfcOupx9O8OR2gVEZO PcpclvIwaD9ZP/w8euxh14TgGD3NFOYNO3gb5YkfsMQ/5P0AOoWyS+FaWGQIMkE9 3/xb6LSGUZpdu9w9SWxcdo4J59+YuthdiJRO7klf2uoWYUl8ejxXJVdqnNkD/t4L XysQQ+0MmNbLmB1ggihGAV3+qeTEIZFoAB+FdtJ8avOXsc0Eob5EBekU6CSeF88= =rak8 -----END PGP SIGNATURE----- --GwTwwm4KOCuuvc0xw87Sg2Dghq7vfOjTJ-- From nobody Thu Apr 9 08:42:11 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7C41B2DBB for ; Thu, 9 Apr 2015 08:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 cis_w7_04h_a for ; Thu, 9 Apr 2015 08:42:09 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (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 6A9151B2D96 for ; Thu, 9 Apr 2015 08:42:08 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so104066655ieb.0 for ; Thu, 09 Apr 2015 08:42:07 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=mOOFNYA4uaxjwG4iSHNse4nYZQK8tX5n1nlyLzFKfI0=; b=IuTc1O45QKpSGHdLSIeqJxxp0tbRrRhg33qqJG7C/55/A80u8+XrbqsgMLUGd9cU1H LSAcKL25LEhB+4+SQ5IDDadTqhxRS5hKI/QxrfngNi+d0lNg2hfaUaeLw10gdX6YwRc8 1CRo7Re7LpTGPMzRATNPPj8CJoVrQZT56H38v5HJkcJ1YEI1m05/QMqdnh3djfFgYIh2 f6jxO3fp894X1T6ofGl7wPrYvNh6oZwHRMpUA/IJIQ9X/APvLocem8a45AU1RKEw6Cbu EUiKF3vDN+l1lOLu2Y/uG/NUO80oEpM/AsoP3ZYUDFPx1c8hTMofhJN2AgDZs7YuSPXJ Qgjg== X-Gm-Message-State: ALoCoQlCYphdpYjBqHIUa3MaMikWMLWlCSx/hXvyuLf7bWfmrm0Dj9sYL+Sk+uuTdufRY+sQH6DP MIME-Version: 1.0 X-Received: by 10.50.142.67 with SMTP id ru3mr21160251igb.16.1428594127581; Thu, 09 Apr 2015 08:42:07 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Thu, 9 Apr 2015 08:42:07 -0700 (PDT) In-Reply-To: <20150409135509.GK24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409135509.GK24286@cisco.com> Date: Thu, 9 Apr 2015 08:42:07 -0700 Message-ID: From: Tom Herbert To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 15:42:11 -0000 On Thu, Apr 9, 2015 at 6:55 AM, Toerless Eckert wrote: > On Thu, Apr 09, 2015 at 09:09:17AM -0400, Phillip Hallam-Baker wrote: >> TCP should probably not happen in the kernel either. Nor should >> printer drivers be in the kernel or anything that does not require the >> intermediation of the security monitor. > > Right. As an OS person i would love for someone to implement a > "raw transport socket" option for unprivileged processes. Implement > in linux, go to POSIX, spend a decade trying to get it proliferated across > OSs. > Good luck on finding an OS vendor willing to give random applications unfettered access to the network. Anyway, you can already do this by just wrapping whatever you want in UDP-- TCP, SCTP, RDMA, whatever. Tom From nobody Thu Apr 9 09:21:38 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AD01A1B46 for ; Thu, 9 Apr 2015 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 5cz-3zipJ9sk for ; Thu, 9 Apr 2015 09:21:36 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34A51A8895 for ; Thu, 9 Apr 2015 09:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1807; q=dns/txt; s=iport; t=1428596494; x=1429806094; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=a2ueIFuzRkLYuvX0siKstsUDQUIlFWMdoQq7sTiZ5Fg=; b=Mxk8w8B6jKJ7u5t1lXtIam0iOhoxX+k7fLZ9RYVMipWaLx0Z+lYqRj4L 59pNYm8g1EHy/CwnP9CRpvbKJVliqYpyYRM5w1JC0UnboWWfqUStuvczq rArgBU0tYMvb8QPAexAqVLGRh0OMUatqeNu7hu/8Vb6msEaLxIH4vivV9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BMBABEpiZV/5tdJa1cgwiBLsRCCYdQAoFBOBQBAQEBAQEBfYQgAQEEOj8QCxgJJQ8FSROIKs42AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4srhHwHhC0FiyePXQGBHY99g0sihA8eMYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,550,1422921600"; d="scan'208";a="139762513" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 09 Apr 2015 16:21:34 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t39GLXJ3013391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 16:21:33 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t39GLWeL019594; Thu, 9 Apr 2015 09:21:32 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t39GLWqH019592; Thu, 9 Apr 2015 09:21:32 -0700 Date: Thu, 9 Apr 2015 09:21:32 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20150409162132.GT24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409135509.GK24286@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 16:21:37 -0000 On Thu, Apr 09, 2015 at 08:42:07AM -0700, Tom Herbert wrote: > On Thu, Apr 9, 2015 at 6:55 AM, Toerless Eckert wrote: > > On Thu, Apr 09, 2015 at 09:09:17AM -0400, Phillip Hallam-Baker wrote: > >> TCP should probably not happen in the kernel either. Nor should > >> printer drivers be in the kernel or anything that does not require the > >> intermediation of the security monitor. > > > > Right. As an OS person i would love for someone to implement a > > "raw transport socket" option for unprivileged processes. Implement > > in linux, go to POSIX, spend a decade trying to get it proliferated across > > OSs. > > > Good luck on finding an OS vendor willing to give random applications > unfettered access to the network. Anyway, you can already do this by > just wrapping whatever you want in UDP-- TCP, SCTP, RDMA, whatever. I didn't say "raw ip socket", "pcap socket" or the like. "raw transport socket"to me means something that behaves pretty much like a UDP socket only that you can select the IP layer protocol from a list of eg: OS level configured options. That list could include all the transport protocols that share the common method of 4-byte demultiplexing header with Sport/Dport. Eg: TCP, SCTP, and a few others. So the kernel would still do the demultiplexing bas on either (*,Dport) for sockets in listening state and (Sport,Dport) for sockets in connected state. But fully agree with your conclusion. This would be design wise nice and clean, but has no business opportunity to it to make it worth our while. Just use UDP and declare it to be the mandatory future OS-level demultiplexer layer for any future transport (+ the discussion that we likely want to have that SPUD like layer for common flow-setup). Cheers Toerless From nobody Thu Apr 9 09:59:29 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05661B2F34 for ; Thu, 9 Apr 2015 09:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 auy8snX9l9WB for ; Thu, 9 Apr 2015 09:59:27 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (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 E60891B2F2F for ; Thu, 9 Apr 2015 09:59:26 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so49762816pab.2 for ; Thu, 09 Apr 2015 09:59:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RcN8Th/zM5EHA3dOImrMuH8M3mo4x7EvF8zHmMzi8Dk=; b=WDPKW5y/f8ugk0O4TogUPnmWS+fvGfHRJn1PBEMBeTFgJrGbB0Xesd2sXYfnVz1JXq oZlrxwdh2cxZLKm6RubMMebYmM/BqnWCVxPteQkVvxXZoS6vgh8kmfOKRkIOgEuMxHQ6 z8/hs0AXSuHVzZVI+PgYSouYEEm/2PLqJSVbsEsfUL79rqz/rF6sy8xJgogv03zCI+nv Y5loDVsYBiq1N77L6+qbjS/dodAcf7nUwAN6T/A7qa9fdVHqbXQ0CeMkZgA/ORQwj/pZ 83NIIMfbkncPwHb1lQSkA7CWsqdS37v0NLRwlAnSYMXuLi2jfKOWQ/3/APxcLcvIyBCW JLhw== X-Gm-Message-State: ALoCoQnQp0fDp5vSnrG61WFgUVnDCiryoBKPGFKLp3mDSRQqmWcOtHRYdUnnXsd49xh96bAYMRTg X-Received: by 10.70.41.81 with SMTP id d17mr58684666pdl.16.1428598766603; Thu, 09 Apr 2015 09:59:26 -0700 (PDT) Received: from Macintosh-2.local (67-207-110-172.static.wiline.com. [67.207.110.172]) by mx.google.com with ESMTPSA id pv4sm14873777pbb.17.2015.04.09.09.59.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 09:59:25 -0700 (PDT) Message-ID: <5526AFF1.8040109@nexenta.com> Date: Thu, 09 Apr 2015 09:59:29 -0700 From: Caitlin Bestler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: spud@ietf.org References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> In-Reply-To: <871tju2rdq.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 16:59:28 -0000 On 4/8/15 3:21 PM, Daniel Kahn Gillmor wrote: > Hi Toerless-- > > On Wed 2015-04-08 15:39:21 -0400, Toerless Eckert wrote: > >> a) I think one hope of SPUDs design is to make UDP look enough like >> TCP to persuade FWs (and similar middleboxes) to police / permit it >> as well as TCP flows are policed/permitted. >> >> b) If you don't like how it works, let me generalize the question, >> would like to hear your (and others) answers: >> >> What is the best possible design we can do to make UDP flows >> be equal or better permissible across WELL BEHAVED FW and similar >> middleboxes ? Please define "WELL BEHAVED"as part of your answer. > As i wrote to Joe, i'm not convinced that this is an answerable question > considering that no one has provided a technical argument yet for why > the enterprise firewall operators can't already do what we're talking > about here. > > With what information? Are you talking about separate switch vendors independently implementing a SPUD-like solution, or are you claiming they already have enough information to perform this with no assist from the endpoints? I believe that endpoint assist in the form of declarative information is necessary to enable optimum network response. Standardizing that information will make it something vendors and endpoint stack developers will support. Without standardization you have a chicken and egg problem that will never be resolved. The key questions are: * Are the hints sufficient to provide optimizations that more than reward the cost of sending the hints? * Are we avoiding creating some form of DOS-vector, which would result in everyone turning off this feature in the field? I suspect there are some refinements that may be needed to avoid enhancing DOS attacks. But we need to set the goal realistically as avoiding *enhanced* attacks, and not rejecting SPUD for being vulnerable to the same attacks that would have worked against TCP. From nobody Thu Apr 9 10:23:03 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2E1A89EB for ; Thu, 9 Apr 2015 10:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 AgCli487DmUc for ; Thu, 9 Apr 2015 10:23:00 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (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 A9BDB1A897B for ; Thu, 9 Apr 2015 10:23:00 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so70582870igb.1 for ; Thu, 09 Apr 2015 10:23:00 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=q1VsTF5aHg4ydfUfSGnZWKHhfK3TtcnY96vFDuosj0s=; b=cKX3R29h9JKqJjwR+r5eT9XvCs1g+zIfG6qrWGpFukhQ5AB7lnZpSMXGkBNwkpdmsw J1gLUI/dqt5/Cgl0zI3goRdSgtVC68liIhkVJRsGvlpetugc/E1i947bd914nKLszyIO XVcn/tOmJfn22QXnsB6boJM90Z2h2ysNKksqbUNqeEo05NoNpleVGIQukehMFLcjxjg/ oZmoVf2/HqTiK5cHMEWIm7KX2IYMpvM/FrepW18ZdJHmDZnExkkO6ijSG6Up8k3DiQv4 fQww2HAXmJWSHcGkNCxW5hSMXvSv+SdidlsVkQtMe/i9oAx9bd3JV0OGzJ6C9+7C28vp JmaA== X-Gm-Message-State: ALoCoQm+qFLiRRvgTE1jTRUuz80OKMBJVDH7qiGTH/jw1zqSYLRj6H6wdaRmGEHL86Ut81rHjmrE MIME-Version: 1.0 X-Received: by 10.107.130.165 with SMTP id m37mr45048073ioi.62.1428600180088; Thu, 09 Apr 2015 10:23:00 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Thu, 9 Apr 2015 10:22:59 -0700 (PDT) In-Reply-To: References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> Date: Thu, 9 Apr 2015 10:22:59 -0700 Message-ID: From: Tom Herbert To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:23:03 -0000 On Thu, Apr 9, 2015 at 6:09 AM, Phillip Hallam-Baker wrote: > On Thu, Apr 9, 2015 at 12:15 AM, Toerless Eckert wrote: >> On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote: >>> I think the kernel/user-land argument is a red herring. >> >> Elaborate please. To me its probably the biggest motivator for >> SPUD. Otherwise we could design all we need into IP and TCP. > > TCP should probably not happen in the kernel either. Nor should > printer drivers be in the kernel or anything that does not require the > intermediation of the security monitor. > > Looking at the shoot-yourself-in-the-foot opportunities in the IPv6 > encoding, I am not exactly anxious to put all those untrusted code > paths in a position where they can root the machine. > > One of the main reasons the current generation of O/S are chronically > insecure is that 90% of the stuff that is inside the security > perimeter has no business being there. > The major Internet security problem now is in embedded systems which are not maintained (which notably includes middleboxes like home routers) (https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html). This is not a OS, userspace, or firmware issue, or even protocol a issue-- but this is an issue with the software deployment model of a wide array of products. I don't know how SPUD will be able to help solve this, but it should at least not make things less secure. > > At this point TCP is water under the bridge. But that does not mean we > are obliged to remake the mistake. > > When TCP was designed, the mantra was 'everything is a stream'. That > was the right abstraction for Telnet and FTP and Mail. It is probably > not the right abstraction for real time web where an unreliable > sequence of chunks seems a better fit. From nobody Thu Apr 9 10:23:45 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDFD1A8A07 for ; Thu, 9 Apr 2015 10:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 0FTSYYh0OIu4 for ; Thu, 9 Apr 2015 10:23:42 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F221A89FC for ; Thu, 9 Apr 2015 10:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2678; q=dns/txt; s=iport; t=1428600222; x=1429809822; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=FfyXuQ7IQHpPapZMIMkE2ZGeqOHv0q+auImym6kt3hg=; b=ZFrta4f70fYdyu6QGLojlVOTZw9pynJucc4jBgxTGsqcUcDbDm18ELOJ WmJ9uX3avYmkQ3vDeC6LxiGC8RtqtEkOjyZv4tNa1GirK1sRy+dlbXgBM m/hSxeYzVNic2iDs0ATeMwpzubqYqI4tGsbH6tJk8UwAHHIxPTAMnI1XL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BPBADotCZV/51dJa1cgwhSXMRECYFJCoV9AoFDOBQBAQEBAQEBfYQgAQEEAQEBNzQLEAsYCSUPBRM2E4gqDc46AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLK4R8B4QtBYsnj10BlGUiggMcgXAeMYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208";a="139778269" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 09 Apr 2015 17:23:41 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t39HNde1024037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 17:23:40 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t39HNdh6023536; Thu, 9 Apr 2015 10:23:39 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t39HNdo1023535; Thu, 9 Apr 2015 10:23:39 -0700 Date: Thu, 9 Apr 2015 10:23:39 -0700 From: Toerless Eckert To: Caitlin Bestler Message-ID: <20150409172339.GW24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <5526AFF1.8040109@nexenta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5526AFF1.8040109@nexenta.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:23:44 -0000 +1 on everything you said, but (*grin*) i think we should layer the analysis: The base layer is analysing how a "session setup/teardown" signaling on top of UDP with an arbitrary transport protocol encapsulated inside of it compares to eg: Native TCP wrt. security and policy for end-to-end operations and FW/middlebox operations. The only bar to pass here is that it should not be significantly worse than TCP. Then the next level is to add the possible enhancements (or others) factored into the SPUD proposals and see how each of them fares. Some of them would have to be compared with other existing approaches. Eg: if the tube ID is an alernative or enhancement to MPTCP, then one would have to compare with that. On the base layer, the main downside i can come up with is that the filtering of invalid protocol packets or sequence of packets is something that ideally should become more easy, because the FW would only have to do it once for SPUD instead of every different transport separately, but alas that is not true because an attacker can still modify the encapsulated transport proto signaling elements, so a FW that would like to provide that state-machinery/packet-header filtering for transport protocols would need to still understand the whole SPUD+Transport stack. Just off the top of my head, the best way out would be to move towards UDP+SPUD+dTLS+reliable-transport, because that would protect that arbitrary transport protocol headers from attacks and would leave FWs with only SPUD and dTLS to worry about. Cheers Toerless On Thu, Apr 09, 2015 at 09:59:29AM -0700, Caitlin Bestler wrote: > I believe that endpoint assist in the form of declarative information > is necessary to enable optimum network response. Standardizing > that information will make it something vendors and endpoint > stack developers will support. Without standardization you have > a chicken and egg problem that will never be resolved. > > The key questions are: > * Are the hints sufficient to provide optimizations that more than > reward the cost of sending the hints? > * Are we avoiding creating some form of DOS-vector, which would > result in everyone turning off this feature in the field? > > I suspect there are some refinements that may be needed to > avoid enhancing DOS attacks. But we need to set the goal > realistically as avoiding *enhanced* attacks, and not rejecting > SPUD for being vulnerable to the same attacks that would have > worked against TCP. > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Thu Apr 9 10:36:57 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105951B2FC3 for ; Thu, 9 Apr 2015 10:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ao248bHU56ql for ; Thu, 9 Apr 2015 10:36:54 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9751B2FC6 for ; Thu, 9 Apr 2015 10:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2173; q=dns/txt; s=iport; t=1428601011; x=1429810611; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=EFj1mufhzHUxS508q203E9cBAAiWNbdfUSjPyKWfens=; b=grWqp16Rmv3KHwswTML+o0WrKPBDua67aheZK1TBwmE/9aUUqM/TSjwK CI5nnId2sHgFcajuhWUryEWWhGyHAIVYxTFxSM/FNkDqQQkJ64pobEsh3 4mhWSx9L3LrhjMuiBwMDSUBVoNChO78kkPFG5/aWQJEG2KQOAwBJc3BN0 E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AwA3uCZV/xbLJq1cg1pcgxXBMQmBVYV7AoF7FAEBAQEBAQF9hCABAQMBI1UBBQsLIRYLAgIJAwIBAgFFBg0BBwEBiB4IDbdpllwBAQEBAQEBAQEBAQEBAQEBAQEBFQSLK4R8B4JogUUBBJJogTOGaoEdhX6GRYcFIoNxPDEBgkIBAQE X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="asc'?scan'208";a="419431122" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 09 Apr 2015 17:36:49 +0000 Received: from [10.61.75.38] (ams3-vpn-dhcp2854.cisco.com [10.61.75.38]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t39HamRK014712; Thu, 9 Apr 2015 17:36:48 GMT Message-ID: <5526B8B0.7050905@cisco.com> Date: Thu, 09 Apr 2015 19:36:48 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tom Herbert References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L3UIiJE131lVumufiCMFCqQkHFSwdRo9K" Archived-At: Cc: Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:36:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L3UIiJE131lVumufiCMFCqQkHFSwdRo9K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 4/9/15 7:22 PM, Tom Herbert wrote: > The major Internet security problem now is in embedded systems which > are not maintained (which notably includes middleboxes like home > routers) (https://www.schneier.com/essays/archives/2014/01/the_internet= _of_thin.html). While it's true home routers get 0wned, they are actually not the biggest problem. The biggest problem will be the orders of magnitude more boxes that are behind those boxes (for those keeping score, home routers=3D O(1), and a house full might very quickly rise to O(100). Of those, maybe O(10) will ever see an update, and those will be general purpose computing devices, and they will only get an update under the best of circumstances. This wouldn't normally be germane to SPUD, but the "I hate middleboxes" mentality only gets you so far. > This is not a OS, userspace, or firmware issue, or even protocol a > issue-- but this is an issue with the software deployment model of a > wide array of products. I don't know how SPUD will be able to help > solve this, but it should at least not make things less secure. It is all of the above, but the fact is that it is also a UI issue, a trust problem, and an economics problem. Eliot --L3UIiJE131lVumufiCMFCqQkHFSwdRo9K 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 iQEcBAEBCAAGBQJVJriwAAoJEIe2a0bZ0noztRUIAMZ0Ywq7136KOouPFJlcJfoR vyuz/bve/xzUAsj6sGPANRlhVvMhe6gyeQRi544HWOHJDEvIIPYpJbb1hnGoURPa lzbJnp8eOxlNBCVyssy0dlAC6D+m/I5Sn6DDbQaPlzI44Rhst1GlzLDReMK32szi NsRb6fr5tElbPPXk5+O240EIyUA8Px9cAOwMu7EzMUzvGC5Kc1YD+oz8TbmmRHj+ lhthN8hpl3WPMN82o8OyPWn15c7j0gco5w47OvRZVY7e6jT7XdFscHQ8AlIgXdYM ss3pFGTkl9ie68XsHUhNyeYClKLBkr8+ixHnPR1iM5y9Q8jtfQsFR6fZ4sctpgc= =bHtl -----END PGP SIGNATURE----- --L3UIiJE131lVumufiCMFCqQkHFSwdRo9K-- From nobody Thu Apr 9 10:46:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9927F1B2FFF for ; Thu, 9 Apr 2015 10:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 zD7HaVyzI2K9 for ; Thu, 9 Apr 2015 10:46:06 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC861B2FFE for ; Thu, 9 Apr 2015 10:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2972; q=dns/txt; s=iport; t=1428601566; x=1429811166; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=stGsGOo14fZPzEYPwRK4MmL4gbmnWUybaogV5tElq20=; b=HLOC3/TuhRTJ0xDVyymZZEUJL4Wu83u9qpI+zpVHSwnAOw4ZKfoDLaQi 6ZhEXmns4+swrl/T5TKfeD54sPyeIlAbP8gGikgJIRi85r/NJ+NPpCQVL 5tuJzyl6fCTZPU38ordjGANrwZAoHFxt/DmnMBgozpS4Do4Gf8h/J/JUe k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BOBADwuSZV/4wNJK1cgwhSXMRHCYFVhXsCgUQ4FAEBAQEBAQF9hCABAQQ6PxALGAklDwVJE4gqDc5DAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLK4QjBwEBB0kHhC0FiyePXQGBHYM6kA4ihA8eMQGBAQEIF4EhAQEB X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208";a="139784754" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 09 Apr 2015 17:46:05 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t39Hk4xi027577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 17:46:05 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t39Hk4Zh024894; Thu, 9 Apr 2015 10:46:04 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t39Hk3hJ024892; Thu, 9 Apr 2015 10:46:03 -0700 Date: Thu, 9 Apr 2015 10:46:03 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20150409174603.GX24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:46:12 -0000 Glad you didn't ask how SPUD can solve world peace, because i am still researching that aspect. There is a lot of work going on wit security models of device deployment, you may want to look at 6LO, 6TISCH, ACE, DICE, ANIMA and there is a lot more outside the IETF. I would see that work as prerequisites to move forward. IN general, i think there is one good and sane device operations method, in IoT which is to NOT upgrade the OS after initial device deployment, but just upgrade/modify applications. And with SPUD, that means you now can upgrade/fix/improve transport layer. Just think of the problem of network based self-upgrade of OS SW in a reliable fashion with limited Flash/NAND storage or the operational issues in IoT for a PXE/AMT Sw upgrade workflow. Lots of challenges with that. Just strip down the OS to the bare minimum for operations with a strong security perimeter, do the rest at the app-level. Cheers Toerless On Thu, Apr 09, 2015 at 10:22:59AM -0700, Tom Herbert wrote: > On Thu, Apr 9, 2015 at 6:09 AM, Phillip Hallam-Baker > wrote: > > On Thu, Apr 9, 2015 at 12:15 AM, Toerless Eckert wrote: > >> On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote: > >>> I think the kernel/user-land argument is a red herring. > >> > >> Elaborate please. To me its probably the biggest motivator for > >> SPUD. Otherwise we could design all we need into IP and TCP. > > > > TCP should probably not happen in the kernel either. Nor should > > printer drivers be in the kernel or anything that does not require the > > intermediation of the security monitor. > > > > Looking at the shoot-yourself-in-the-foot opportunities in the IPv6 > > encoding, I am not exactly anxious to put all those untrusted code > > paths in a position where they can root the machine. > > > > One of the main reasons the current generation of O/S are chronically > > insecure is that 90% of the stuff that is inside the security > > perimeter has no business being there. > > > The major Internet security problem now is in embedded systems which > are not maintained (which notably includes middleboxes like home > routers) (https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html). > This is not a OS, userspace, or firmware issue, or even protocol a > issue-- but this is an issue with the software deployment model of a > wide array of products. I don't know how SPUD will be able to help > solve this, but it should at least not make things less secure. > > > > > At this point TCP is water under the bridge. But that does not mean we > > are obliged to remake the mistake. > > > > When TCP was designed, the mantra was 'everything is a stream'. That > > was the right abstraction for Telnet and FTP and Mail. It is probably > > not the right abstraction for real time web where an unreliable > > sequence of chunks seems a better fit. From nobody Thu Apr 9 11:40:25 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00361A889C for ; Thu, 9 Apr 2015 11:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 mKQEfJbp87L4 for ; Thu, 9 Apr 2015 11:40:21 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (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 986271A8896 for ; Thu, 9 Apr 2015 11:40:21 -0700 (PDT) Received: by igblo3 with SMTP id lo3so72411099igb.0 for ; Thu, 09 Apr 2015 11:40:21 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=QWamnalH0+Tm71EohJePTDQsNaFT8i63XrHIRsLDH/4=; b=Ra3Ni/AOwpQ2iLH9ltJJC7SqXrS8Hjemygod2JUDBoQMDohszMmXiBfS8LW1CI05mI s/g/KSTHty5GISiYVNIDkQgMQ+e3ik5A/Kla6yEf4tdtFUo7YFxbiJJZ6ERPPoXUm3Yq WsG8gn4UwqB07hAAzWDSQ4yeVyWaAWkhrIFMbly7ddJL51+gBBcxNuDi+2t6TdsW+pxp MfAzkKpzs0nm8DEktCPr8LWeuqgRWa9FmvKe6TB6/oqE433A0P6pU7tYaD1ODD1Kycts odLNPZT9dhnt5kmtH10Lh6K+hrxclQEp1tgnkowxj16S5GfAMlMl/4/g25MVQUITgusn z5jg== X-Gm-Message-State: ALoCoQm/gD79Kh9gx/mXop1qHnxFjGG9DcMTBqDEGnVtu9AznbJuOzQlHYzB96mMDS+P86iCVOnU MIME-Version: 1.0 X-Received: by 10.107.164.209 with SMTP id d78mr49078459ioj.73.1428604821020; Thu, 09 Apr 2015 11:40:21 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Thu, 9 Apr 2015 11:40:20 -0700 (PDT) In-Reply-To: <20150409174603.GX24286@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409174603.GX24286@cisco.com> Date: Thu, 9 Apr 2015 11:40:20 -0700 Message-ID: From: Tom Herbert To: Toerless Eckert Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:40:23 -0000 On Thu, Apr 9, 2015 at 10:46 AM, Toerless Eckert wrote: > Glad you didn't ask how SPUD can solve world peace, because i am > still researching that aspect. > > There is a lot of work going on wit security models of device deployment, > you may want to look at 6LO, 6TISCH, ACE, DICE, ANIMA and there is a > lot more outside the IETF. I would see that work as prerequisites > to move forward. > > IN general, i think there is one good and sane device operations method, > in IoT which is to NOT upgrade the OS after initial device deployment, > but just upgrade/modify applications. And with SPUD, that means you > now can upgrade/fix/improve transport layer. > Well, there's already over a billion smartphones in the world which are already regularly updating their OS and this hasn't yet led to mass anarchy. You can certainly make avoiding OS updates and avoiding OS in general a design point for your products, but this is not a relevant design point or requirement for a networking protocol. As I said, it's a red herring wrt SPUD. > Just think of the problem of network based self-upgrade of OS SW in a > reliable fashion with limited Flash/NAND storage or the operational > issues in IoT for a PXE/AMT Sw upgrade workflow. Lots of challenges with that. > > Just strip down the OS to the bare minimum for operations with a strong > security perimeter, do the rest at the app-level. > > Cheers > Toerless > > On Thu, Apr 09, 2015 at 10:22:59AM -0700, Tom Herbert wrote: >> On Thu, Apr 9, 2015 at 6:09 AM, Phillip Hallam-Baker >> wrote: >> > On Thu, Apr 9, 2015 at 12:15 AM, Toerless Eckert wrote: >> >> On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote: >> >>> I think the kernel/user-land argument is a red herring. >> >> >> >> Elaborate please. To me its probably the biggest motivator for >> >> SPUD. Otherwise we could design all we need into IP and TCP. >> > >> > TCP should probably not happen in the kernel either. Nor should >> > printer drivers be in the kernel or anything that does not require the >> > intermediation of the security monitor. >> > >> > Looking at the shoot-yourself-in-the-foot opportunities in the IPv6 >> > encoding, I am not exactly anxious to put all those untrusted code >> > paths in a position where they can root the machine. >> > >> > One of the main reasons the current generation of O/S are chronically >> > insecure is that 90% of the stuff that is inside the security >> > perimeter has no business being there. >> > >> The major Internet security problem now is in embedded systems which >> are not maintained (which notably includes middleboxes like home >> routers) (https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html). >> This is not a OS, userspace, or firmware issue, or even protocol a >> issue-- but this is an issue with the software deployment model of a >> wide array of products. I don't know how SPUD will be able to help >> solve this, but it should at least not make things less secure. >> >> > >> > At this point TCP is water under the bridge. But that does not mean we >> > are obliged to remake the mistake. >> > >> > When TCP was designed, the mantra was 'everything is a stream'. That >> > was the right abstraction for Telnet and FTP and Mail. It is probably >> > not the right abstraction for real time web where an unreliable >> > sequence of chunks seems a better fit. From nobody Thu Apr 9 11:51:30 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD881A8827 for ; Thu, 9 Apr 2015 11:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 r9M25GrLkHtf for ; Thu, 9 Apr 2015 11:51:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7A31A882F for ; Thu, 9 Apr 2015 11:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4294; q=dns/txt; s=iport; t=1428605484; x=1429815084; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fYatKimSngwhuDQWn2Vrtx0CidF6ZXx9oKn3QjWLEIk=; b=fST2w430ixjzZC4gLAeUTtlZQ5Bm+aH6RDPzOaCiGY6kbDVN77PPZnIP oI3tk7FXrTZG8Qq1+DY2un6KoSRBT3bU0FjD5l/+GPW4yxB2IFMsc7Nnx E5VtRZEgoFbBeJl83vI+NL0tVOhimZfdYL6rg+T4NbE2NGeIHYrP7k6Z8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CKBQCxySZV/4sNJK1cgwhSXMYohX8CgUVMAQEBAQEBfoQgAQEEOj8QCxgJJQ8FSROIKg3OTgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyuEIwcBAQcHQgeELQWLK49gAYEdgzeMQ4NLIoIDHIFwHjEBgQEBAQcXgSEBAQE X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208";a="410566313" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 09 Apr 2015 18:51:23 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t39IpN0m004594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 18:51:23 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t39IpMlp029362; Thu, 9 Apr 2015 11:51:22 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t39IpL6n029361; Thu, 9 Apr 2015 11:51:21 -0700 Date: Thu, 9 Apr 2015 11:51:21 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20150409185121.GZ24286@cisco.com> References: <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409174603.GX24286@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:51:29 -0000 If all IoT devices could hace a touchscreen and personal operator bringing them to places for failed upgrade help and 70% of them would be 48 monthly throwaways that never get upgraded anyhow, i would certainly want to clone the smartphone operational model to those IoT devices. Just look at the uproar generated recently for security attacks against BIOSs. You need clear security perimeters, and the question is why a reliable transport stack for an app would need to be in a more secure perimeter than the app itself. On Thu, Apr 09, 2015 at 11:40:20AM -0700, Tom Herbert wrote: > On Thu, Apr 9, 2015 at 10:46 AM, Toerless Eckert wrote: > > Glad you didn't ask how SPUD can solve world peace, because i am > > still researching that aspect. > > > > There is a lot of work going on wit security models of device deployment, > > you may want to look at 6LO, 6TISCH, ACE, DICE, ANIMA and there is a > > lot more outside the IETF. I would see that work as prerequisites > > to move forward. > > > > IN general, i think there is one good and sane device operations method, > > in IoT which is to NOT upgrade the OS after initial device deployment, > > but just upgrade/modify applications. And with SPUD, that means you > > now can upgrade/fix/improve transport layer. > > > Well, there's already over a billion smartphones in the world which > are already regularly updating their OS and this hasn't yet led to > mass anarchy. You can certainly make avoiding OS updates and avoiding > OS in general a design point for your products, but this is not a > relevant design point or requirement for a networking protocol. As I > said, it's a red herring wrt SPUD. > > > Just think of the problem of network based self-upgrade of OS SW in a > > reliable fashion with limited Flash/NAND storage or the operational > > issues in IoT for a PXE/AMT Sw upgrade workflow. Lots of challenges with that. > > > > Just strip down the OS to the bare minimum for operations with a strong > > security perimeter, do the rest at the app-level. > > > > Cheers > > Toerless > > > > On Thu, Apr 09, 2015 at 10:22:59AM -0700, Tom Herbert wrote: > >> On Thu, Apr 9, 2015 at 6:09 AM, Phillip Hallam-Baker > >> wrote: > >> > On Thu, Apr 9, 2015 at 12:15 AM, Toerless Eckert wrote: > >> >> On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote: > >> >>> I think the kernel/user-land argument is a red herring. > >> >> > >> >> Elaborate please. To me its probably the biggest motivator for > >> >> SPUD. Otherwise we could design all we need into IP and TCP. > >> > > >> > TCP should probably not happen in the kernel either. Nor should > >> > printer drivers be in the kernel or anything that does not require the > >> > intermediation of the security monitor. > >> > > >> > Looking at the shoot-yourself-in-the-foot opportunities in the IPv6 > >> > encoding, I am not exactly anxious to put all those untrusted code > >> > paths in a position where they can root the machine. > >> > > >> > One of the main reasons the current generation of O/S are chronically > >> > insecure is that 90% of the stuff that is inside the security > >> > perimeter has no business being there. > >> > > >> The major Internet security problem now is in embedded systems which > >> are not maintained (which notably includes middleboxes like home > >> routers) (https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html). > >> This is not a OS, userspace, or firmware issue, or even protocol a > >> issue-- but this is an issue with the software deployment model of a > >> wide array of products. I don't know how SPUD will be able to help > >> solve this, but it should at least not make things less secure. > >> > >> > > >> > At this point TCP is water under the bridge. But that does not mean we > >> > are obliged to remake the mistake. > >> > > >> > When TCP was designed, the mantra was 'everything is a stream'. That > >> > was the right abstraction for Telnet and FTP and Mail. It is probably > >> > not the right abstraction for real time web where an unreliable > >> > sequence of chunks seems a better fit. -- --- Toerless Eckert, eckert@cisco.com From nobody Thu Apr 9 13:36:34 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4351B3215 for ; Thu, 9 Apr 2015 13:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Onv5CdZHUs_O for ; Thu, 9 Apr 2015 13:36:31 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 D30E61A88F1 for ; Thu, 9 Apr 2015 13:36:29 -0700 (PDT) Received: by widjs5 with SMTP id js5so2601146wid.1 for ; Thu, 09 Apr 2015 13:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4SIB7Stp4fr7H9WVSO8g/mp/ahPfLSU5BDYWvoEvXNw=; b=PLNMppsx9VNcAzP7WPIL8qh8TxNDNpsBT3mZSRS1FOmLdXaA/nYR1fDulrENGw9Z7L yEk3gXNI8AmBwjOaKGIzRGDrqWsyOiaAgKvpx5rrXplsktayl+bYHernd6aSDO705UUy UGLO3ULIsjVn3GSwlwWzY5MPydFu77DwXWfJHK3qH4f5X9hRyT8huYo/cHDsm3ffKk0Z fCMuKlU7jfYFyF2r9ax2Ed8A07RGFwoUvhQn5iIn1gtthhl2KEu8NWp3anrZ5CLCEnIN WVAP5bC59skGZoPuNvmVgFpaoFde4gUERwiwTJ6PaOhntnXkMFhrtsxAzxJUgeY1JWft V7eA== X-Received: by 10.194.177.195 with SMTP id cs3mr62157843wjc.141.1428611788663; Thu, 09 Apr 2015 13:36:28 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id o5sm571764wia.0.2015.04.09.13.36.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Apr 2015 13:36:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 9 Apr 2015 23:36:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409174603.GX24286@cisco.com> To: Tom Herbert X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Toerless Eckert , Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:36:32 -0000 > On Apr 9, 2015, at 9:40 PM, Tom Herbert wrote: >=20 > On Thu, Apr 9, 2015 at 10:46 AM, Toerless Eckert = wrote: >> Glad you didn't ask how SPUD can solve world peace, because i am >> still researching that aspect. >>=20 >> There is a lot of work going on wit security models of device = deployment, >> you may want to look at 6LO, 6TISCH, ACE, DICE, ANIMA and there is a >> lot more outside the IETF. I would see that work as prerequisites >> to move forward. >>=20 >> IN general, i think there is one good and sane device operations = method, >> in IoT which is to NOT upgrade the OS after initial device = deployment, >> but just upgrade/modify applications. And with SPUD, that means you >> now can upgrade/fix/improve transport layer. >>=20 > Well, there's already over a billion smartphones in the world which > are already regularly updating their OS and this hasn't yet led to > mass anarchy. You can certainly make avoiding OS updates and avoiding > OS in general a design point for your products, but this is not a > relevant design point or requirement for a networking protocol. As I > said, it's a red herring wrt SPUD. There are also over a billion smartphones stuck in an old version of the = OS. Android 2.6 is very popular as is the latest iOS version your phone = supports (lots of iPhone 4 out there, and they=E2=80=99re not getting = iOS 8). And don=E2=80=99t get me started on desktop operating systems. By = NetApp=E2=80=99s numbers just under 17% of desktop and laptop systems = are running Windows XP. The majority are running the already outdated = Windows 7. And those phones and desktops are things people are always looking at. = Lots of people do upgrade the OS on their phones and computers when = given a choice. How many people are going to want to upgrade the OS on = their refrigerator, car fuel-injection system, air conditioner, or = industrial sensor? Those things are deep into =E2=80=9Cif it works - = don=E2=80=99t fix it=E2=80=9D territory. Yoav= From nobody Thu Apr 9 14:09:15 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4511B331C for ; Thu, 9 Apr 2015 14:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 5G_L46qFhrKf for ; Thu, 9 Apr 2015 14:09:10 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (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 3C6741B3300 for ; Thu, 9 Apr 2015 14:09:10 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so97304919lbb.2 for ; Thu, 09 Apr 2015 14:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=jtVEXFkFzpmYv7vZWTNBtg7dJk2ZfL12X2SHxFytUmc=; b=FcAr0oyJ7yQEjyWNyzsvzKwz0OMlmdMmV8oC5ymBVRVO10hTF3d1n4eGkrRBHgBvhB VAlv51DUW8lrCW8H5wcM098jhsfvE1rM0Jcb07kGtOowSXgNv6lQNBMejll6fqQMwzTV URtF9Os1eaPbqkb6C0JS1S0SA5nYjpMu7va7WuDnbDUy2OmNwqpTG0sLYy8Zh2mo/Mop DCNRc4G2x+TujWGN61W2WQ7PcY5lkn60Y+Yq940SpjQrYA9hkBfQ7LpvWpLnlsBIDr93 lq1HertC4/DwMU4iTRqWMzjfrJtcNFK1OhJ14ZYC+2CHhqZ1qy7N9owsNwWr4HAQHtdR Ub6A== MIME-Version: 1.0 X-Received: by 10.152.87.162 with SMTP id az2mr6272203lab.58.1428613748685; Thu, 09 Apr 2015 14:09:08 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Thu, 9 Apr 2015 14:09:08 -0700 (PDT) Date: Thu, 9 Apr 2015 17:09:08 -0400 X-Google-Sender-Auth: dtwti3ozsFZ3tdAy4ryApJ7jN98 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tom Herbert , Toerless Eckert , Daniel Kahn Gillmor , "spud@ietf.org" Subject: [Spud] OS updates on embedded devices X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:09:12 -0000 We are quite a way afield here. But there are very good reasons for NOT wanting automatic updates. Security for me means that the device does what I want it to and nothing else. Having the system change behavior because some code monkey decided to add some Kewl features is a security vulnerability as far as I am concerned. I have Sonos devices in some of the rooms. They are practically unusable because the idiots who make the app insist on making changes that require the already sluggish iPhone app to be updated regularly. When I want to turn the radio on I want it to take less than a second. Sonos is already slow. But when it asks for an update of the app, someone has to bring the phone to me and have me enter the password to update it. Then the device will often fail to find the app store. If it does find it then it is another five minutes to load the new app. If a network device did the same thing it would undoubtedly break my network. From nobody Thu Apr 9 14:38:48 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA481B3325 for ; Thu, 9 Apr 2015 14:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 X3H8ZETaDbVq for ; Thu, 9 Apr 2015 14:38:46 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (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 41A481B304A for ; Thu, 9 Apr 2015 14:38:41 -0700 (PDT) Received: by igblo3 with SMTP id lo3so3287382igb.0 for ; Thu, 09 Apr 2015 14:38:40 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=enYQip4REEQSc+Sg3XMQysXuF8GBahKmiciVRDiwZWc=; b=mBtMX3YvZNWxrDxeSlBgskMCPNn8UUpV7cicVgPAXN1wu6X4uvu8dbFdiy3oD/WDFm s4WYInKajZMpMWRhFFKz9DkNld6/FEH2yuRPYOuQPMaM1jf+iGKLhrdoi5GXko7SkS1M zqfq60GAXt8ny9ca5ktEahUzDU544EdXeWS/g9zLmGbrz40AGrDr7rkBWvlP+7CxSyX0 MhQjm/kBKXUQL9hFgOKYuzweEK9+5jXLgwDrQ9AcymMlnHo1vmqBE4OGwlSo94NTIoNd 64Sf8PNACiOw23K1A7+zuJo5OfcN718nMiTkttqGthj9Rdrkeji31dmf4JGrjd0AAQ7s S4sA== X-Gm-Message-State: ALoCoQmR1avlVmHfUKvSnN28DWTkRkd9d5ok9o1sUpXUJczv9mjGFCq4hPz7daPeSSuSu6XP04zB MIME-Version: 1.0 X-Received: by 10.107.164.209 with SMTP id d78mr50219543ioj.73.1428615520713; Thu, 09 Apr 2015 14:38:40 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Thu, 9 Apr 2015 14:38:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Apr 2015 14:38:40 -0700 Message-ID: From: Tom Herbert To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , Daniel Kahn Gillmor , Yoav Nir , "spud@ietf.org" Subject: Re: [Spud] OS updates on embedded devices X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:38:47 -0000 On Thu, Apr 9, 2015 at 2:09 PM, Phillip Hallam-Baker wrote: > We are quite a way afield here. But there are very good reasons for > NOT wanting automatic updates. > > Security for me means that the device does what I want it to and > nothing else. Having the system change behavior because some code > monkey decided to add some Kewl features is a security vulnerability > as far as I am concerned. > > I have Sonos devices in some of the rooms. They are practically > unusable because the idiots who make the app insist on making changes > that require the already sluggish iPhone app to be updated regularly. > > When I want to turn the radio on I want it to take less than a second. > Sonos is already slow. But when it asks for an update of the app, > someone has to bring the phone to me and have me enter the password to > update it. Then the device will often fail to find the app store. If > it does find it then it is another five minutes to load the new app. > > > If a network device did the same thing it would undoubtedly break my network. This discussion is probably more relevant in the IoT and security lists. But anyway, as we start attaching more and more devices to the the Internet they eventually become targets. One known problem we face is that security vulnerabilities, unlike simple bugs, are usually not caught in initial development. It's only after significant deployment that would-be attackers get interest in this. So our choices are: don't connect devices, update software (wherever it is) on running devices, live with security vulnerabilities, buy new HW, have devices live behind other devices that provide security, etc. Given that these devices are targeted to end users and that some serve life critical functions (like you smoke detector), a transparent solution seems essential. Tom From nobody Thu Apr 9 14:45:23 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D301B3395 for ; Thu, 9 Apr 2015 14:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hLUcxxFcOLMF for ; Thu, 9 Apr 2015 14:45:20 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 742F51B3390 for ; Thu, 9 Apr 2015 14:45:20 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 603F01A01CB; Thu, 9 Apr 2015 23:44:49 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9469EDCA-1529-49EA-AD3A-B0EC91518C77"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: Date: Thu, 9 Apr 2015 23:44:48 +0200 Message-Id: References: To: Tom Herbert X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Toerless Eckert , Phillip Hallam-Baker , Yoav Nir , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] OS updates on embedded devices X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:45:22 -0000 --Apple-Mail=_9469EDCA-1529-49EA-AD3A-B0EC91518C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What I take away from this tangent: avoiding certain types of badness is = probably a necessary function of any minimal common transport such as = SPUD. Which types of badness those are is a point for detailed = discussion, but it probably includes avoiding anything that looks like = reflection or amplification, and anything that looks like trivial state = exhaustion, which we need to consider very carefully in a protocol = designed to make state establishment on path explicit. Thanks, cheers, Brian > On 09 Apr 2015, at 23:38, Tom Herbert wrote: >=20 > On Thu, Apr 9, 2015 at 2:09 PM, Phillip Hallam-Baker > wrote: >> We are quite a way afield here. But there are very good reasons for >> NOT wanting automatic updates. >>=20 >> Security for me means that the device does what I want it to and >> nothing else. Having the system change behavior because some code >> monkey decided to add some Kewl features is a security vulnerability >> as far as I am concerned. >>=20 >> I have Sonos devices in some of the rooms. They are practically >> unusable because the idiots who make the app insist on making changes >> that require the already sluggish iPhone app to be updated regularly. >>=20 >> When I want to turn the radio on I want it to take less than a = second. >> Sonos is already slow. But when it asks for an update of the app, >> someone has to bring the phone to me and have me enter the password = to >> update it. Then the device will often fail to find the app store. If >> it does find it then it is another five minutes to load the new app. >>=20 >>=20 >> If a network device did the same thing it would undoubtedly break my = network. >=20 > This discussion is probably more relevant in the IoT and security > lists. But anyway, as we start attaching more and more devices to the > the Internet they eventually become targets. One known problem we face > is that security vulnerabilities, unlike simple bugs, are usually not > caught in initial development. It's only after significant deployment > that would-be attackers get interest in this. So our choices are: > don't connect devices, update software (wherever it is) on running > devices, live with security vulnerabilities, buy new HW, have devices > live behind other devices that provide security, etc. Given that these > devices are targeted to end users and that some serve life critical > functions (like you smoke detector), a transparent solution seems > essential. >=20 > Tom >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_9469EDCA-1529-49EA-AD3A-B0EC91518C77 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 iQEcBAEBCgAGBQJVJvLQAAoJENt3nsOmbNJc3ScH/2hY02gPwWXGGz+eGerjAIsv s08JGnTCL9y46Z6Bge64nBG033O5Aiy+n2pXzE+SZaLf6xns+X24bsd1pWNkXNxT Cm976p9QvjQo85qHK9yW4wJoO7NutY/a9leDvEznF4hoqmIx5/q7iqjeofe6ju1u V/8518aSY9/GVBNhpI/cq/kKndaa1aNXnzB2hhNJC/j5XMIXhas+hdsRi8pUBj7/ YBdEIkfbSy+cLDOwb3WrFv4y8yZSORUcRzxDcwSqBgKxRamfqHwlbU3U3/GpMNpo wLsFYYc60+qtKXg9YIweIhmu4BCSojK6N0/WjGLqQXSKaMDL0UJyEFor9GdXSyw= =n1Z3 -----END PGP SIGNATURE----- --Apple-Mail=_9469EDCA-1529-49EA-AD3A-B0EC91518C77-- From nobody Thu Apr 9 14:53:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91D11A1BDB for ; Thu, 9 Apr 2015 14:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 XQRfDJsDgaxU for ; Thu, 9 Apr 2015 14:53:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528E71A8742 for ; Thu, 9 Apr 2015 14:53:02 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (0.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (0.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 9 Apr 2015 21:52:59 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([0.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([0.160.96.17]) with mapi id 15.01.0130.020; Thu, 9 Apr 2015 21:52:59 +0000 From: Christian Huitema To: Brian Trammell , Tom Herbert Thread-Topic: [Spud] OS updates on embedded devices Thread-Index: AQHQcwlwP0NzOv/EcEGx1Vu7wmsnMp1FNQMAgAABtwCAAAEJgA== Date: Thu, 9 Apr 2015 21:52:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.254] authentication-results: trammell.ch; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(2656002)(76176999)(54356999)(46102003)(66066001)(99286002)(86362001)(76576001)(50986999)(106116001)(74316001)(92566002)(122556002)(2900100001)(15975445007)(33656002)(102836002)(40100003)(19580395003)(87936001)(77156002)(2950100001)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0541031FF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2015 21:52:59.3438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: Toerless Eckert , Phillip Hallam-Baker , Daniel Kahn Gillmor , Yoav Nir , "spud@ietf.org" Subject: Re: [Spud] OS updates on embedded devices X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:53:03 -0000 On Thursday, April 9, 2015, at 2:45 PM, Brian Trammell wrote >=20 > What I take away from this tangent: avoiding certain types of badness is > probably a necessary function of any minimal common transport such as SPU= D. > Which types of badness those are is a point for detailed discussion, but = it > probably includes avoiding anything that looks like reflection or amplifi= cation, > and anything that looks like trivial state exhaustion, which we need to c= onsider > very carefully in a protocol designed to make state establishment on path > explicit. >=20 Agreed. In particular, "no worse than TCP" is a bit of a low bar. We need t= o be robust against packet injection attacks. As for IoT, did we not have a couple of IoT talks during the last IAB plena= ry? Most of what I read on this thread was presented here: http://www.ietf.= org/proceedings/92/slides/slides-92-iab-techplenary-2.pdf. The discussion s= hould probably move to an IoT specific list. -- Christian Huitema From nobody Thu Apr 9 15:20:32 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966491B3468 for ; Thu, 9 Apr 2015 15:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 B10TVaRnKDTB for ; Thu, 9 Apr 2015 15:20:26 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (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 D4C571B346B for ; Thu, 9 Apr 2015 15:20:25 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so1369593pac.1 for ; Thu, 09 Apr 2015 15:20:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=as0iohEpJfyZcLw7fK97Tq+D86F0olH2Td3uKbyG590=; b=XUF5pQto0dQAdR3nJqkvaXNwyz2q4pOZLY+p+ncfYqJsqRnDjAw+v0pHKgkooJ5PmN PB76rsuTjf0BwYa3s8bF/2JKd4IRnw5f8eRp35IuUjZ1BB/05o6nyh4jSGqwii2nV8KH KhAR47lJqM2On4jRvi90sJzMfHQb+QKBjqb5Wnux7gq3Kq6qR+042nr+UCs4N81ijLYG TTCKOIc343vlw52T1P8dEN1MqR+ifRZlk8Y2kTZGlLy2lDzCB+WyIa5pbZnkmjDByGNh wwrYf3qBKqmTY+nS9kfwQ8jba/P7TB7xv2j8pL8uWqZB2SHeipLzC4oSUVkR3H6sEFw/ 4FNg== X-Gm-Message-State: ALoCoQnLy+Cnj948PZ0zw1EHhQAylb3l9DEfwNPIbS7KYfshGrp+iRkgfeXBBjSoMwAJA15d5kuR X-Received: by 10.70.47.138 with SMTP id d10mr25493210pdn.137.1428618025501; Thu, 09 Apr 2015 15:20:25 -0700 (PDT) Received: from Macintosh-2.local (67-207-110-172.static.wiline.com. [67.207.110.172]) by mx.google.com with ESMTPSA id pj8sm51654pdb.20.2015.04.09.15.20.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 15:20:24 -0700 (PDT) Message-ID: <5526FB2C.90706@nexenta.com> Date: Thu, 09 Apr 2015 15:20:28 -0700 From: Caitlin Bestler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: spud@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spud] OS updates on embedded devices X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:20:28 -0000 On 4/9/15 2:52 PM, Christian Huitema wrote: > On Thursday, April 9, 2015, at 2:45 PM, Brian Trammell wrote >> What I take away from this tangent: avoiding certain types of badness is >> probably a necessary function of any minimal common transport such as SPUD. >> Which types of badness those are is a point for detailed discussion, but it >> probably includes avoiding anything that looks like reflection or amplification, >> and anything that looks like trivial state exhaustion, which we need to consider >> very carefully in a protocol designed to make state establishment on path >> explicit. >> > Agreed. In particular, "no worse than TCP" is a bit of a low bar. We need to be robust against packet injection attacks. > > We should make SPUD as good as possible. But we should not *reject* a solution merely because it does not achieve some ideal as long as it is "no worse than TCP" and provides *some* benefit. If there are clear areas where we are "worse than TCP" then we probably don't want to proceed to even an experimental standard, because as you note - TCP is a low bar to compare against. From nobody Thu Apr 9 17:07:03 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A631B37AF for ; Thu, 9 Apr 2015 17:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 OE7gcewD8FTt for ; Thu, 9 Apr 2015 17:06:57 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (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 437A31B37A9 for ; Thu, 9 Apr 2015 17:06:51 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so5450619igb.1 for ; Thu, 09 Apr 2015 17:06:50 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q941hPLU8m3L9yyJRhQg/WWK0Hdq2eyFOReLs+K1PaE=; b=RosEy5Of6VMUWvPHS3Un4SkPbo+T0Iz1598a8vNcJySu0ovGapVWcpqNdj09S+cVZX IpnHzuCYUwgWtRf+FaKyWdwyBwpDraPFMXsNwpkSTPveVo1OxcPPYbbUwIRjsNQ70QAb dD6rBt9ykQmHfqkoLyKlmSqL0Mv83gQPOsspCp0o95vQPQGCotWxFq3IJRnaYCCqz26l rb0dHzM5mNXgqxe4GHea+j1nXQUurwNYKFoKDatloDsO61Moyf8tQK+W5sf1yUHQ/pU8 k7V0Pke1eA/u73wQpiTIo1F8ADZvi8DCj2tYlmsVL9L2WAdfoKMaXvIVagaS5gpQMdd2 Xj0w== X-Gm-Message-State: ALoCoQlazmHNtmwEurN1Tsb39CLJZPHQrnpS2SFnbCfVes4uuK4ZelGWd7DtBGBEH+UPWn1TVkjn MIME-Version: 1.0 X-Received: by 10.50.97.41 with SMTP id dx9mr23981378igb.1.1428624410671; Thu, 09 Apr 2015 17:06:50 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Thu, 9 Apr 2015 17:06:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Apr 2015 17:06:50 -0700 Message-ID: From: Tom Herbert To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , Phillip Hallam-Baker , Yoav Nir , "spud@ietf.org" , Brian Trammell , Daniel Kahn Gillmor Subject: Re: [Spud] OS updates on embedded devices X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 00:07:02 -0000 On Thu, Apr 9, 2015 at 2:52 PM, Christian Huitema w= rote: > On Thursday, April 9, 2015, at 2:45 PM, Brian Trammell wrote >> >> What I take away from this tangent: avoiding certain types of badness is >> probably a necessary function of any minimal common transport such as SP= UD. >> Which types of badness those are is a point for detailed discussion, but= it >> probably includes avoiding anything that looks like reflection or amplif= ication, >> and anything that looks like trivial state exhaustion, which we need to = consider >> very carefully in a protocol designed to make state establishment on pat= h >> explicit. >> > > Agreed. In particular, "no worse than TCP" is a bit of a low bar. We need= to be robust against packet injection attacks. > That is a good requirement which is directed more at the transport layer itself rather than the middleboxes-DPI interaction. I don't see that requirements like this are listed in the SPUD drafts, have they been enumerated somewhere? Thanks, Tom > As for IoT, did we not have a couple of IoT talks during the last IAB ple= nary? Most of what I read on this thread was presented here: http://www.iet= f.org/proceedings/92/slides/slides-92-iab-techplenary-2.pdf. The discussion= should probably move to an IoT specific list. > > -- Christian Huitema > From nobody Thu Apr 9 18:30:46 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53381A8980 for ; Thu, 9 Apr 2015 18:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 zTRFB_3lWDqM for ; Thu, 9 Apr 2015 18:30:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC8B1A896F for ; Thu, 9 Apr 2015 18:30:44 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (0.160.96.17) by DM2PR0301MB0768.namprd03.prod.outlook.com (0.160.97.151) with Microsoft SMTP Server (TLS) id 15.1.136.25; Fri, 10 Apr 2015 01:30:42 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (0.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (0.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 10 Apr 2015 01:30:42 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([0.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([0.160.96.17]) with mapi id 15.01.0130.020; Fri, 10 Apr 2015 01:30:42 +0000 From: Christian Huitema To: Tom Herbert Thread-Topic: [Spud] OS updates on embedded devices Thread-Index: AQHQcwlwP0NzOv/EcEGx1Vu7wmsnMp1FNQMAgAABtwCAAAEJgIAAJqYAgAAVxlA= Date: Fri, 10 Apr 2015 01:30:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.254] authentication-results: herbertland.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0768; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(377454003)(2900100001)(2950100001)(86362001)(87936001)(93886004)(54356999)(50986999)(76576001)(76176999)(102836002)(110136001)(46102003)(77156002)(106116001)(92566002)(62966003)(33656002)(2656002)(99286002)(74316001)(66066001)(122556002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 054231DC40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2015 01:30:41.8548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: Toerless Eckert , Phillip Hallam-Baker , Yoav Nir , "spud@ietf.org" , Brian Trammell , Daniel Kahn Gillmor Subject: Re: [Spud] OS updates on embedded devices X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 01:30:45 -0000 T24gVGh1cnNkYXksIEFwcmlsIDksIDIwMTUsIGF0IDU6MDcgUE0sIFRvbSBIZXJiZXJ0IHdyb3Rl Og0KPiAuLi4NCj4gPiBBZ3JlZWQuIEluIHBhcnRpY3VsYXIsICJubyB3b3JzZSB0aGFuIFRDUCIg aXMgYSBiaXQgb2YgYSBsb3cgYmFyLiBXZSBuZWVkIHRvIGJlDQo+IHJvYnVzdCBhZ2FpbnN0IHBh Y2tldCBpbmplY3Rpb24gYXR0YWNrcy4NCj4gPg0KPiBUaGF0IGlzIGEgZ29vZCByZXF1aXJlbWVu dCB3aGljaCBpcyBkaXJlY3RlZCBtb3JlIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIgaXRzZWxmDQo+ IHJhdGhlciB0aGFuIHRoZSBtaWRkbGVib3hlcy1EUEkgaW50ZXJhY3Rpb24uIA0KDQpBY3R1YWxs eSwgaXQgaXMgYWxzbyBhIHJlcXVpcmVtZW50IG9uIHRoZSBtaWRkbGVib3hlcy4gVGFrZSB0aGUg ZXhhbXBsZSBvZiB0aGUgc3Bvb2ZlZCByZXNldCBhdHRhY2suIEVuZCB0byBlbmQgdHJhbnNwb3J0 IGNhbiBwcm90ZWN0IHRoZW1zZWx2ZXMgZWFzaWx5IGFnYWluc3QgdGhhdCBieSBydW5uaW5nIG9u IHRvcCBvZiBEVExTLiBUaGUgc3Bvb2ZlZCBwYWNrZXRzIHdpbGwganVzdCBiZSBkcm9wcGVkIGJl Y2F1c2UgdGhleSBkb24ndCBwYXNzIGF1dGhlbnRpY2F0aW9uLiBCdXQgd2hhdCBpZiB0aGUgbWlk ZGxlYm94ZXMganVzdCBuYWl2ZWx5IGNsb3NlcyB0aGUgcG9ydCBiZWNhdXNlIGl0IHNhdyB0aGUg InN0b3AiIGJpdCBpbiBhIHNwb29mZWQgcGFja2V0PyBUaGUgZW5kIHN5c3RlbXMgY2Fubm90IGRv IGFueXRoaW5nIGFib3V0IHRoYXQuDQoNCj4gLi4uIEkgZG9uJ3Qgc2VlIHRoYXQgcmVxdWlyZW1l bnRzIGxpa2UNCj4gdGhpcyBhcmUgbGlzdGVkIGluIHRoZSBTUFVEIGRyYWZ0cywgaGF2ZSB0aGV5 IGJlZW4gZW51bWVyYXRlZCBzb21ld2hlcmU/DQoNCldlIGNvdWxkIHVzZSBhIHNlY3VyaXR5IGFu YWx5c2lzIGZvciBTUFVELiBKdXN0IGNvbGxlY3RpbmcgdGhlIG1lc3NhZ2VzIGV4Y2hhbmdlZCBy ZWNlbnRseSB3b3VsZCBiZSBhIHN0YXJ0Lg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg== From nobody Thu Apr 9 19:35:51 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAFB1A90D8 for ; Thu, 9 Apr 2015 19:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 zFmT7oo7JxkL for ; Thu, 9 Apr 2015 19:35:48 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (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 4BE241A90D4 for ; Thu, 9 Apr 2015 19:35:48 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so7366022ieb.3 for ; Thu, 09 Apr 2015 19:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=zrX8Ipwtovyqzg2IWbuomMHxYynidPenfGQvhZsxzDo=; b=aCw4mvUD8fkCCfjWwj5lUYPzZup7OF9kCYHuLfhPpzsGj924WC766L0K4+1v0scijE TMLxt6x1aaNOg5nGKmIhfLD87jrzSzuXr9M0BZ++dEugK4Ork+a1dTjB7WjFjqc951OP Zw6A62sxHJyd0+4O5RnCV3q0e8vu+mt4sjkIqUBBpLR+G/rTMKKLxPN8AIfdFKsQOPY4 pJ2fAg4t1Z7U7/T+3ia4YIlbIfvvsC3eNZgQuvoLmoGk0KXm6nfgV9y+hyou5biuiPO0 G00FwItxBV2GP9u6UdyDiNv0dppObi5vhJUKljaz3u38qO7ZTxs1nOAeEtE6Bluz8yLu iTNg== X-Gm-Message-State: ALoCoQldrv5KtPl857BJXtIS1v20FhikuDhqTV75zbsm1zgnOH2ydeczoRgB+HKHMkBSWXF4JTml MIME-Version: 1.0 X-Received: by 10.50.142.67 with SMTP id ru3mr25098874igb.16.1428633347773; Thu, 09 Apr 2015 19:35:47 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Thu, 9 Apr 2015 19:35:47 -0700 (PDT) Date: Thu, 9 Apr 2015 19:35:47 -0700 Message-ID: From: Tom Herbert To: spud@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Spud] SPUD magic number X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 02:35:50 -0000 Hi, The SPUD magic number seems like a good idea and in fact I anticipate that we'll want to adopt this technique in other UDP encapsulation protocols. I believe the magic number could be applied in two different ways: 1) A middlebox must match both the UDP destination port and the magic number before accepting the packet is SPUD protocol. In this case , the magic number is used to distinguish SPUD from other arbitrary uses of a SPUD assigned port. 2) A middlebox matches the magic number in any UDP packet regardless of destination port and declares it to be SPUD. This is nice because we would not need to configure SPUD ports on middleboxes, but increases the chances of misinterpreting something which is not SPUD at all (a larger magic number size might be warranted). What is the intended use for this in the SPUD prototype protocol? Thanks, Tom From nobody Fri Apr 10 00:12:50 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1E91A009E for ; Fri, 10 Apr 2015 00:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 tLF-E9fBA_Ff for ; Fri, 10 Apr 2015 00:12:48 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991891A009B for ; Fri, 10 Apr 2015 00:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2978; q=dns/txt; s=iport; t=1428649968; x=1429859568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8Os5DY4M9F7uHcCaBTx5IfbB0iyCuPxN0ffM8d+Jk94=; b=WUnToR2lrw0asuoqvg3cybz1zozUj/MlQUPftSlfocg81PTsrLdSckTk DIuwvufQMOWlKsnZ3sPdyE3BdVybV0xph6gMf/XkXfQqNZcAvFZVyfx/c MI762uRRc2SxpygbYRwmuT8HEUbmHtwlbullAJotAhHUuFeIrQLUleXqf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeBACSdidV/51dJa1cgwxSXAWDEMFBCYFECoYBAhyBKDgUAQEBAQEBAX2EHwEBAQMBAQEBIBE6CwULAgEIGAICJgICAiULFRACBA4FiCIIDbdcllcBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhigqESTMHgmgvgRYFkQODeIYUgR2PfINMIoIDHIFQb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,555,1422921600"; d="scan'208";a="139952946" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 10 Apr 2015 07:12:47 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3A7ClFX024430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Apr 2015 07:12:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.233]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 10 Apr 2015 02:12:47 -0500 From: "Pal Martinsen (palmarti)" To: Tom Herbert Thread-Topic: [Spud] SPUD magic number Thread-Index: AQHQczcRa9I0LYd8BE2BbTGlCFnVEJ1GKN2A Date: Fri, 10 Apr 2015 07:12:47 +0000 Message-ID: <430F4C7C-7565-48C1-833B-45F9E0D5F6B2@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.204.130] Content-Type: text/plain; charset="utf-8" Content-ID: <59637933883A774BB5CD89A6C7F37F4A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD magic number X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 07:12:50 -0000 DQo+IE9uIDEwIEFwciAyMDE1LCBhdCAwNDozNSwgVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFu ZC5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPiBUaGUgU1BVRCBtYWdpYyBudW1iZXIgc2Vl bXMgbGlrZSBhIGdvb2QgaWRlYSBhbmQgaW4gZmFjdCBJIGFudGljaXBhdGUNCj4gdGhhdCB3ZSds bCB3YW50IHRvIGFkb3B0IHRoaXMgdGVjaG5pcXVlIGluIG90aGVyIFVEUCBlbmNhcHN1bGF0aW9u DQo+IHByb3RvY29scy4NCj4gDQorMQ0KDQpTVFVOIChSRkM1Mzg5KSBhbHNvIHVzZXMgdGhpcyB0 cmljayBpbiBzZWN0aW9uIDYgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Mzg5I3Nl Y3Rpb24tNikNCg0KPiBJIGJlbGlldmUgdGhlIG1hZ2ljIG51bWJlciBjb3VsZCBiZSBhcHBsaWVk IGluIHR3byBkaWZmZXJlbnQgd2F5czoNCj4gDQo+IDEpIEEgbWlkZGxlYm94IG11c3QgbWF0Y2gg Ym90aCB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgYW5kIHRoZSBtYWdpYw0KPiBudW1iZXIgYmVm b3JlIGFjY2VwdGluZyB0aGUgcGFja2V0IGlzIFNQVUQgcHJvdG9jb2wuIEluIHRoaXMgY2FzZSAs DQo+IHRoZSBtYWdpYyBudW1iZXIgaXMgdXNlZCB0byBkaXN0aW5ndWlzaCBTUFVEIGZyb20gb3Ro ZXIgYXJiaXRyYXJ5IHVzZXMNCj4gb2YgYSBTUFVEIGFzc2lnbmVkIHBvcnQuDQo+IDIpIEEgbWlk ZGxlYm94IG1hdGNoZXMgdGhlIG1hZ2ljIG51bWJlciBpbiBhbnkgVURQIHBhY2tldCByZWdhcmRs ZXNzDQo+IG9mIGRlc3RpbmF0aW9uIHBvcnQgYW5kIGRlY2xhcmVzIGl0IHRvIGJlIFNQVUQuIFRo aXMgaXMgbmljZSBiZWNhdXNlDQo+IHdlIHdvdWxkIG5vdCBuZWVkIHRvIGNvbmZpZ3VyZSBTUFVE IHBvcnRzIG9uIG1pZGRsZWJveGVzLCBidXQNCj4gaW5jcmVhc2VzIHRoZSBjaGFuY2VzIG9mIG1p c2ludGVycHJldGluZyBzb21ldGhpbmcgd2hpY2ggaXMgbm90IFNQVUQNCj4gYXQgYWxsIChhIGxh cmdlciBtYWdpYyBudW1iZXIgc2l6ZSBtaWdodCBiZSB3YXJyYW50ZWQpLg0KPiANCj4gV2hhdCBp cyB0aGUgaW50ZW5kZWQgdXNlIGZvciB0aGlzIGluIHRoZSBTUFVEIHByb3RvdHlwZSBwcm90b2Nv bD8NCj4gDQpUaGlzIHdhcyBhY3R1YWxseSB0aGUgZmlyc3QgYmV0IHdlIGltcGxlbWVudGVkICho dHRwczovL2dpdGh1Yi5jb20vaXB0dWJlL1NQVURsaWIpLiBNb3N0bHkgZHVlIHRvIHlvdXIgMikg YnVsbGV0IHBvaW50LiANCg0KSXQgYWxsb3dlZCB1cyB0byBxdWlja2x5IGdldCBhIGxpbnV4IHJv dXRlciB3aXRoIG5ldGZpbGV0ci9pcHRhYmxlcyB1cCBhbmQgcnVubmluZyB3aXRoIHRoZSBmb2xs b3dpbmcgcnVsZToNCg0KLUEgUFJFUk9VVElORyAtcCB1ZHAg4oCUbWF0Y2ggdTMyIC0tdTMyICIw Pj4yMiYweDNDQDg9MHhkODAwMDBkOCIgLWogTkZRVUVVRSAtLXF1ZXVlLW51bSAwDQoNClNlZSBo dHRwczovL2dpdGh1Yi5jb20vaXB0dWJlL1R1YmVOb2RlIGZvciBhIHF1aWNrIGFuZCBkaXJ0eSBp bXBsZW1lbnRhdGlvbi4NCg0KRnJvbSBhIGNsaWVudCBwZXJzcGVjdGl2ZSBsZXNzb25zIGxlYXJu ZWQgZnJvbSBpbXBsZW1lbnRpbmcgSUNFIGFuZCBTVFVOIHdoZXJlIFJUUCwgU1RVTiBhbmQgdmlk ZSB2YXJpZXR5IG9mIG90aGVyIHBhY2tldHMgbWlnaHQgYmUgbXVsdGlwbGV4ZWQgb24gdGhlIHNh bWUgcG9ydCB3YXMgdGhhdCBoYXZpbmcgYSBzaW1wbGUgaXNTUFVEIGZ1bmN0aW9uIGlzIHJlYWxs eSB1c2VmdWwuLg0KDQpJbiB0aGUgc3B1ZCBwcm90b3R5cGUgaXQgaXMgZGVmaW5lZCBsaWtlIHRo aXM6DQoNCmJvb2wgc3B1ZF9pc19zcHVkKGNvbnN0IHVpbnQ4X3QgKnBheWxvYWQsIHNpemVfdCBs ZW5ndGgpDQp7DQogICAgaWYgKGxlbmd0aCA8IHNpemVvZihzcHVkX2hlYWRlcikpIHsNCiAgICAg ICAgcmV0dXJuIGZhbHNlOw0KICAgIH0NCiAgICByZXR1cm4gKG1lbWNtcChwYXlsb2FkLCAodm9p ZCAqKVNwdWRNYWdpY0Nvb2tpZSwgU1BVRF9NQUdJQ19DT09LSUVfU0laRSkgPT0gMCk7DQp9DQoN Ci4tLg0KUMOlbC1FcmlrDQoNCj4gVGhhbmtzLA0KPiBUb20NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNwdWQgbWFpbGluZyBsaXN0DQo+ IFNwdWRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cHVkDQoNCg== From nobody Fri Apr 10 00:17:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4821A00D8 for ; Fri, 10 Apr 2015 00:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sSEycwRhA_JC for ; Fri, 10 Apr 2015 00:17:23 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396111A007D for ; Fri, 10 Apr 2015 00:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1329; q=dns/txt; s=iport; t=1428650243; x=1429859843; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=g7R1+7h5qbNA13CT7HEMhCS38GZVEkYK36BxJbGceYY=; b=iFggAGjLwq34SN9suxq11xzG3Y4G1URutt5nhThvMMavYHL2xey3HFVT IRrLDW4RIn7SRzRH5Xzldq5eRwijItI3sov+78eJdkfvQFT5BHNLr7Xu/ osPT1j8k37+1HGBV/FVbthV1N5UaxVvw9fY/XY+/PCwhrlefinMBdfYaq c=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.11,555,1422921600"; d="asc'?scan'208";a="419889806" 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; 10 Apr 2015 07:17:20 +0000 Received: from [10.61.75.38] (ams3-vpn-dhcp2854.cisco.com [10.61.75.38]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3A7HKOb031078; Fri, 10 Apr 2015 07:17:20 GMT Message-ID: <55277900.1010006@cisco.com> Date: Fri, 10 Apr 2015 09:17:20 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christian Huitema , Brian Trammell , Tom Herbert References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bdBKTmsd6EldFtJkFmKtagN819vHPqJuS" Archived-At: Cc: Toerless Eckert , Phillip Hallam-Baker , Yoav Nir , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] OS updates on embedded devices X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 07:17:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bdBKTmsd6EldFtJkFmKtagN819vHPqJuS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/9/15 11:52 PM, Christian Huitema wrote: > Agreed. In particular, "no worse than TCP" is a bit of a low bar. We ne= ed to be robust against packet injection attacks. Everyone wants a pony. The whole point of that tangent is that there are many tradeoffs to be considered. Ruling things out without considering those tradeoffs would be as inappropriate as demanding them. Eliot --bdBKTmsd6EldFtJkFmKtagN819vHPqJuS 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 iQEcBAEBCAAGBQJVJ3kAAAoJEIe2a0bZ0nozWREIAMMy7fIGs1EL9b4Oa5WOD69L 2+zFznGzSXIMshFIrAvO2U+vFkMl1erZF2I4AKEs1I3yIYwFkD1FgckBCv5PbdYY ylhEgcPRcaNAREbclVT8PaDi5o7wPKoHRGnFNcYopMNvuERxainLDh7eqDwq44Yg E0gUVHqSGSxF5bHty8lu0X04J8X/co8q/GRdJO+p3DZbdyd4t8lGIr+Vq8ByjjuZ k5iq78rM5AoIRVCqcMT0tZgT9I3W1fMqBl0UULXfKd4Rc74SktSE02awAzGIeG5O lnGCJUIyNtn9ASS3yTTpGPOv37JmQXwo0+aqXM93AvEy+FUowwNf5IVs0rRO8gg= =Mhqb -----END PGP SIGNATURE----- --bdBKTmsd6EldFtJkFmKtagN819vHPqJuS-- From nobody Fri Apr 10 10:26:38 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3E1A8859 for ; Fri, 10 Apr 2015 10:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 RNW2LT0VFBjK for ; Fri, 10 Apr 2015 10:26:35 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (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 9BF831A885E for ; Fri, 10 Apr 2015 10:26:35 -0700 (PDT) Received: by iget9 with SMTP id t9so18283345ige.1 for ; Fri, 10 Apr 2015 10:26:35 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=WSzOqHSpg9qeyyCvCMK63ItcDP1lzw76JrAKFg534io=; b=TkX79WfL3fk1r1TMVOz2cSqZn6RpAXKe0XK8L+vPUdeHuN/SmAPjE5qnS+exY8ViWW M+SS9KbDAuiyrNU1IqvxPIgVd5uZg3NezNEd59lVg7n2ilDzJYTnFLYGTNbLG9K4lFw9 IyD/eYnqA5n6YvevGz1e8JDQZi1cr/HWlO7BMvwZe8/XWtvViNzd796mXZ7apyVutLPV y4s4xt9cNZIUfQiUf0mDgr3FGN7ir2qG32qpFI/F+nyPixwXmRBUnAjWkMhkqK247COI Hl0pExnSroJ4ChKOMxaeldro36d0kvTe1di5YX2uacFxcT1vVBMfw+TjE7beWIa3QzqQ r5Ag== X-Gm-Message-State: ALoCoQkd5KtU7xfJNnoivFbsIGUCB1zuMvWzZzUZ7WZ9z4QI5kHF7Ev2n0lpKK7gaLa6QL0ZwGIA MIME-Version: 1.0 X-Received: by 10.107.130.165 with SMTP id m37mr4259558ioi.62.1428686795068; Fri, 10 Apr 2015 10:26:35 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Fri, 10 Apr 2015 10:26:34 -0700 (PDT) In-Reply-To: <430F4C7C-7565-48C1-833B-45F9E0D5F6B2@cisco.com> References: <430F4C7C-7565-48C1-833B-45F9E0D5F6B2@cisco.com> Date: Fri, 10 Apr 2015 10:26:34 -0700 Message-ID: From: Tom Herbert To: "Pal Martinsen (palmarti)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD magic number X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 17:26:37 -0000 On Fri, Apr 10, 2015 at 12:12 AM, Pal Martinsen (palmarti) wrote: > >> On 10 Apr 2015, at 04:35, Tom Herbert wrote: >> >> Hi, >> >> The SPUD magic number seems like a good idea and in fact I anticipate >> that we'll want to adopt this technique in other UDP encapsulation >> protocols. >> > +1 > > STUN (RFC5389) also uses this trick in section 6 (https://tools.ietf.org/html/rfc5389#section-6) > >> I believe the magic number could be applied in two different ways: >> >> 1) A middlebox must match both the UDP destination port and the magic >> number before accepting the packet is SPUD protocol. In this case , >> the magic number is used to distinguish SPUD from other arbitrary uses >> of a SPUD assigned port. >> 2) A middlebox matches the magic number in any UDP packet regardless >> of destination port and declares it to be SPUD. This is nice because >> we would not need to configure SPUD ports on middleboxes, but >> increases the chances of misinterpreting something which is not SPUD >> at all (a larger magic number size might be warranted). >> >> What is the intended use for this in the SPUD prototype protocol? >> > This was actually the first bet we implemented (https://github.com/iptube/SPUDlib). Mostly due to your 2) bullet point. > 32 bits seems a little light to me for this usage #2, especially if when some application packet inadvertently matches the magic number packet is dropped when it would have otherwise been accepted if magic numbers weren't being checked. 64 bits might be safer. For UDP encapsulations (GUE, Geneve, VXLAN, etc), we probably would the magic number to be optional since we'll already have a port number to identify the protocol (at the client) and might not need middlebox support within a data center. To make the magic number optional, we need a way to distinguish the magic number from a valid encapsulation header. I was thinking to set the first byte of magic number to 0xff and declaring that indicates an invalid header for the encapsulation protocol. 0xff works nicely since most of the new UDP encapsulations have a version number in the first byte and haven't got past version zero, so this gives forward compatibility. Tom From nobody Fri Apr 10 10:33:06 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF91A88F3 for ; Fri, 10 Apr 2015 10:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ggzm582Wm9hW for ; Fri, 10 Apr 2015 10:33:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8481A8857 for ; Fri, 10 Apr 2015 10:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3259; q=dns/txt; s=iport; t=1428687184; x=1429896784; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=IJsl788LjZtagYVPjI87+HDId/PfOKIrTIsZ/ObIMjA=; b=hN2YpF2/mgBEceJ5rWGxdPSIlU6NpcLdlxXh49h+p5cFyc5LWhklrAcm r6TTE71v/Du+BK+aSpIjZGDfWKI/P9i4bkFu62pkF+Ad/ed9eohXV9Wml Hjkia86mdnVTMH7B2NGcWsdY3NaB8Oe+XaR1jeieTqdkuLSB9LQzXPAVY s=; X-IronPort-AV: E=Sophos;i="5.11,557,1422921600"; d="scan'208";a="410867674" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 10 Apr 2015 17:33:03 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3AHX2Qs017432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2015 17:33:03 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t3AHX2Pu022629; Fri, 10 Apr 2015 10:33:02 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t3AHX256022628; Fri, 10 Apr 2015 10:33:02 -0700 Date: Fri, 10 Apr 2015 10:33:02 -0700 From: Toerless Eckert To: "Pal Martinsen (palmarti)" Message-ID: <20150410173302.GE24286@cisco.com> References: <430F4C7C-7565-48C1-833B-45F9E0D5F6B2@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <430F4C7C-7565-48C1-833B-45F9E0D5F6B2@cisco.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , "spud@ietf.org" Subject: Re: [Spud] SPUD magic number X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 17:33:05 -0000 In STUN/ICE there is also a checksum that can be checked. That gives 32 bit for extraction from HW for CMDs, and then another 32 bits of checksum to be done in SW, so that you ultimately only had 1/2^64 for false positives. Unless somebody explains me why not, i would recommend such a checksum for SPUD cmd != 0 packets as well. The 1/2^64 certainty + parsing of packets should then be good enough to protect any middlebox action that could happen on cmd = 0 packets, because for any middlebox action that needs a really high certainty that it is really SPUD traffic, the cmd != 0 packets could be used to learn the tube ID, and later on the packet cmd = 0 recognition could be based on the 96 bits of cookie + tun-ID. Cheers Toerless On Fri, Apr 10, 2015 at 07:12:47AM +0000, Pal Martinsen (palmarti) wrote: > > > On 10 Apr 2015, at 04:35, Tom Herbert wrote: > > > > Hi, > > > > The SPUD magic number seems like a good idea and in fact I anticipate > > that we'll want to adopt this technique in other UDP encapsulation > > protocols. > > > +1 > > STUN (RFC5389) also uses this trick in section 6 (https://tools.ietf.org/html/rfc5389#section-6) > > > I believe the magic number could be applied in two different ways: > > > > 1) A middlebox must match both the UDP destination port and the magic > > number before accepting the packet is SPUD protocol. In this case , > > the magic number is used to distinguish SPUD from other arbitrary uses > > of a SPUD assigned port. > > 2) A middlebox matches the magic number in any UDP packet regardless > > of destination port and declares it to be SPUD. This is nice because > > we would not need to configure SPUD ports on middleboxes, but > > increases the chances of misinterpreting something which is not SPUD > > at all (a larger magic number size might be warranted). > > > > What is the intended use for this in the SPUD prototype protocol? > > > This was actually the first bet we implemented (https://github.com/iptube/SPUDlib). Mostly due to your 2) bullet point. > > It allowed us to quickly get a linux router with netfiletr/iptables up and running with the following rule: > > -A PREROUTING -p udp ???match u32 --u32 "0>>22&0x3C@8=0xd80000d8" -j NFQUEUE --queue-num 0 > > See https://github.com/iptube/TubeNode for a quick and dirty implementation. > > >From a client perspective lessons learned from implementing ICE and STUN where RTP, STUN and vide variety of other packets might be multiplexed on the same port was that having a simple isSPUD function is really useful.. > > In the spud prototype it is defined like this: > > bool spud_is_spud(const uint8_t *payload, size_t length) > { > if (length < sizeof(spud_header)) { > return false; > } > return (memcmp(payload, (void *)SpudMagicCookie, SPUD_MAGIC_COOKIE_SIZE) == 0); > } > > .-. > Pål-Erik > > > Thanks, > > Tom > > > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Apr 10 10:48:57 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59561AC3E1 for ; Fri, 10 Apr 2015 10:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2xfDH7i8a7tu for ; Fri, 10 Apr 2015 10:48:54 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EC51AC3CB for ; Fri, 10 Apr 2015 10:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2423; q=dns/txt; s=iport; t=1428688135; x=1429897735; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=jAFwghCEim5yhz61YKCnDcpHe45iPPUgUCe1nySRIec=; b=XLShHT/RUDa9fqE3IMZ5dtzEIzGymEcc4+nKoE81uxp4chKf2b2LqYyb A0PYQK+Qe4elyv7Frd9BB8rdaKCsm4/Yp72HC62c/zfMJu6OghohYpMcu ufLRtYcXSzZA3N+ahD1Qba5fAbJm+lD4R9sbiJmZ8PIxr1YXQHym02r6D o=; X-IronPort-AV: E=Sophos;i="5.11,557,1422921600"; d="scan'208";a="140135408" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 10 Apr 2015 17:48:54 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3AHmrmn019829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2015 17:48:53 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t3AHmqjf023582; Fri, 10 Apr 2015 10:48:52 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t3AHmqac023581; Fri, 10 Apr 2015 10:48:52 -0700 Date: Fri, 10 Apr 2015 10:48:52 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20150410174852.GF24286@cisco.com> References: <430F4C7C-7565-48C1-833B-45F9E0D5F6B2@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "spud@ietf.org" Subject: Re: [Spud] SPUD magic number X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 17:48:56 -0000 On Fri, Apr 10, 2015 at 10:26:34AM -0700, Tom Herbert wrote: > 32 bits seems a little light to me for this usage #2, especially if > when some application packet inadvertently matches the magic number > packet is dropped when it would have otherwise been accepted if magic > numbers weren't being checked. 64 bits might be safer. See my last email of how we ultimately would get 1/2^96 false positive in middleboxes that are keeping today per-flow state and with SPUD would do per-tube state. > For UDP encapsulations (GUE, Geneve, VXLAN, etc), we probably would > the magic number to be optional since we'll already have a port number > to identify the protocol (at the client) and might not need middlebox > support within a data center. Even if just meant to be used for end-to-end signaling, i would not remove the cookie. Its still very helpfull for end-to-end communication, especially for any communication where it is not upfront clear whether SPUD is used or not. And if there is prior signaling that makes the endpoints know SPUD is used, then the cookie is easy to skip. And hopefully the 32 bits are not going to be so valuable space (SPUD tax..) that we need to make them optional. I think the most important design goal should be to ensure that it is easy for middleboxes to distinguish different type of "awareness" int SPUD traffic, so that a middlebox would only need to inspect what it is intersted in. For example: A middlebox that ONLY wants to do a lightweight tracking of flows would simply set up snoop punt entry in the forwarding plane for cookie+cmd=01, cookie+cmd=02, cookie+cmd=03. And it would never see data packets, but just connection setup/teardown. With this in mind, i think it would be a lot better if SPUD had 8 bit of CMD, and that would give us the ability to distinguish additional levels of awareness through additional new CMDs, and only the middleboxes interested in those commands would have to snoop those command packets its interested in. And we could of course also simply say that the high order bit = 0 or 1 is an indication whether middleboxes are allowed to look at (and potentially modify) the packet. Cheers Toerless > > Tom > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Fri Apr 10 15:20:50 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD411B2DC2 for ; Fri, 10 Apr 2015 15:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 bhz0ytGrTB9O for ; Fri, 10 Apr 2015 15:20:48 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (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 C85BA1B2DC1 for ; Fri, 10 Apr 2015 15:20:47 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so28500898ieb.0 for ; Fri, 10 Apr 2015 15:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jVE59hUORKdVDVHgG3oNwGUHayFoUO7MCpkZ3pxxcyE=; b=CIN7HFgjVJkr7rmi/9yQ/GQpl+DA3+ll+DZ4oiNAMRzMbOCcvDDuXo7iUOtTT6aVID KorNdzOjA5guZmYNCtxecv5dbZBK0Bh1pMjADgabub9jD9SVrGDZ6AShjEj6SOSmicpI 6pvOAQMuUDBM5ZBcpjSqJq0qskbZSNM0XQ28MXat9r+cP3TskCF3KGtRFCYaCmg70hcB Rh6rUtEynbNjH+6JiMQ/t8/9a69sf/xfPyh96MV/Jo2sJFcO14As6lxDc67NpDIeYdqL Z4LTNDxkJilq0UZDgDf2hQTl4J1gp57U/ncFiIa9Td/CZx8hA0GaxYAGlzQgMN4RR2a8 e15g== 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:date :message-id:subject:from:to:cc:content-type; bh=jVE59hUORKdVDVHgG3oNwGUHayFoUO7MCpkZ3pxxcyE=; b=Bghkw+FtlyHIEyPwsyNoZww0CaXQQGVPMOFGoUoWnXhQP21+XhL3+R+JK0uaElvdv/ W+Wm4Zxbxmvna6DPR1rhHFlsEW/EV7k0SjumKvQD78GzqoTE91Kg2hn0updTwqwqQ2Ya OYpLkM1LnMnJH3CG3JeZQGPUqVXQ7CkQt4XAPRwH8Pn8pAVStGRJ5qiFg0TR5h07KwDx 0CyqZ7KWT/bUj1EU/aiwCMIVubj4wPBFYZX8Io8gvOCWww2BSaFOQLKUzjsuxrbTZj4c 3QJ8mQSoZ/k9ItQhgXcjEGY38zL5KsVo6xjL1zoGRKoY+avejZSLqCeR92HDPcxm+lQe tiZQ== X-Gm-Message-State: ALoCoQlEkDBeR9D9n4e7XII/oC4jsI0jdR3Di/m1MCPJGEQdvZ2ZRjAZuKLJO1CGB595nJ9VQJjp MIME-Version: 1.0 X-Received: by 10.50.43.130 with SMTP id w2mr1509164igl.30.1428704447061; Fri, 10 Apr 2015 15:20:47 -0700 (PDT) Received: by 10.50.45.41 with HTTP; Fri, 10 Apr 2015 15:20:46 -0700 (PDT) In-Reply-To: <55261A99.5090801@cisco.com> References: <87iod631nv.fsf@alice.fifthhorseman.net> <55261A99.5090801@cisco.com> Date: Fri, 10 Apr 2015 15:20:46 -0700 Message-ID: From: Jana Iyengar To: Eliot Lear Content-Type: multipart/alternative; boundary=089e0103de4e0e8c310513662d15 Archived-At: Cc: Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 22:20:49 -0000 --089e0103de4e0e8c310513662d15 Content-Type: text/plain; charset=UTF-8 Eliot, A few responses: Open provides an indication that the flow is not a continuation, that new > state should be instantiated, that any old state of the 5-tuple should be > discarded. Opens may flow in either direction, but may be authorized for > only some uses. > If used like this, it creates another DoS vector where anyone can trivially kick someone else's connection off. > Close is unreliable > ------------------- > > One of the reasons on-path equipment would like a "close" signal is so > that they know when to tear down associations that are no longer needed. > This would reduce memory consumption and make a device more resilient to > DoS attacks that exhaust its connection table. Without "close", the > on-path equipment has to rely on timers to decide when to tear down the > connection. > > Unfortunately, we can't rely on endpoints to send Close. Legitimate > endpoints crash, run out of power, or have their network connectivity > cut. > > > This is by far the exception and not the rule. Most state is torn down. > AFAIK, TCP connections are commonly torn down with an RST (not a FIN), and not infrequently with silence. I would love to know what the truth is -- is there any data that I can look at to prove myself wrong? So on-path equipment needs to maintain timers anyway if they're > tracking flow state instead of just passing IP traffic statelessly. > > > This misses the point. If there is an implicit understanding of the > behavior of the endpoints, firewalls needn't keep state. It is sufficient > in many cases to know that SYNs should be blocked whereas SYN|ACK should be > passed. No state retained on the firewall. There is no equivalent in UDP > without going up the stack. > > Moreover, if a firewall is tracking state, it cannot tell if an incoming > packet is a continuation of a or an initiation if it is > *not* using timers. This makes both open and close (as well as perhaps > some other gunk) very useful. > Why does it need to tell the difference? I'm not sure I see a use case at the middlebox for using this information. > And > in a DoS scenario, it's trival for an actively malicious end-point to > send lots of "open" messages without ever sending a "close", so it > doesn't protect against DoS either. > > > In fact, this is precisely the nature of a SYN attack. Firewalls > regularly detect and block them in TCP. UDP requires much more effort and > understanding of the higher layers. > Why would a DoS attacker set the OPEN bit in SPUD if it will thwart their attack? That would be silly... --089e0103de4e0e8c310513662d15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eliot,

A few responses:

<= div class=3D"gmail_extra">
Open provides an indication that the flow is not a continuation, that new state should be instantiated, that any old state of the 5-tuple should be discarded.=C2=A0 Opens may flow in either direction, but may be authorized for only some uses.

If used like this, it creates another DoS vector where anyone can = trivially kick someone else's connection off.
=C2=A0
Close is unreliable
-------------------

One of the reasons on-path equipment would like a "close" signal =
is so
that they know when to tear down associations that are no longer needed.
This would reduce memory consumption and make a device more resilient to
DoS attacks that exhaust its connection table.  Without "close", =
the
on-path equipment has to rely on timers to decide when to tear down the
connection.

Unfortunately, we can't rely on endpoints to send Close.  Legitimate
endpoints crash, run out of power, or have their network connectivity
cut.

This is by far the exception and not the rule.=C2=A0 Most state is torn down.

AFAIK, TCP connections are = commonly torn down with an RST (not a FIN), and not infrequently with silen= ce. I would love to know what the truth is -- is there any data that I can = look at to prove myself wrong?

  So on-path equipment needs to maintain timers anyway if they&#=
39;re
tracking flow state instead of just passing IP traffic statelessly.

 This misses the point.=C2=A0 If there is an implicit understanding of t= he behavior of the endpoints, firewalls needn't keep state.=C2=A0 It i= s sufficient in many cases to know that SYNs should be blocked whereas SYN|ACK should be passed.=C2=A0 No state retained on the firewall.=C2= =A0 There is no equivalent in UDP without going up the stack.

Moreover, if a firewall is tracking state, it cannot tell if an incoming packet is a continuation of a <flow/spud/tube> or an initiation if it is not using timers.=C2=A0 This makes both open and close (as well as perhaps some other gunk) very useful.

Why does it need to tell the difference? I'm= not sure I see a use case at the middlebox for using this information.
= 
  And
in a DoS scenario, it's trival for an actively malicious end-point to
send lots of "open" messages without ever sending a "close&q=
uot;, so it
doesn't protect against DoS either.

 In fact, this is precisely the nature of a SYN attack.=C2=A0 Firewalls regularly detect and block them in TCP.=C2=A0 UDP requires much more effort and understanding of the higher layers.
<= br>
Why would a DoS attacker set the OPEN bit in SPUD if it will = thwart their attack? That would be silly...
=C2=A0
--089e0103de4e0e8c310513662d15-- From nobody Fri Apr 10 15:24:15 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E511B2DCB for ; Fri, 10 Apr 2015 15:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 7EMgn-DReE-L for ; Fri, 10 Apr 2015 15:24:11 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 81AA51B2DC9 for ; Fri, 10 Apr 2015 15:24:11 -0700 (PDT) Received: by iggg4 with SMTP id g4so9365217igg.0 for ; Fri, 10 Apr 2015 15:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vl/mulvnqNWO6ZwSJUU/INjxlzZumgZmC9i2UQySuJU=; b=lcgvREseV9sJfQVXwwQD2m2k1FWGYTi3+u6c0FVpOLz46jR7e5tHT/tMH+gHhbGJHT +dZURM5YLdVW3GxGgD9hoVtIchtlOskblNLLMTj1/lJ2QMhuFVUH0y7qetqu6shNsPa+ lfbXvjMc0b9vctJQ/PX1lz4q32PO5kOM/KV8psFIhVVWR8EKTgokpqziFiKQbCsI2gEu I9FybAcV+u2N1rHy8oU24ZZ8scvw70606TqDnO0C0m98SNyIxCq+mEyse1N7WGFhO2LL LGvU9+1MGHV/jVwo2drIDPTKXueeMNB9rfVprZrPYax6cZEcK9A5pyu9bW9/52N8ufh6 wuNw== 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:date :message-id:subject:from:to:cc:content-type; bh=vl/mulvnqNWO6ZwSJUU/INjxlzZumgZmC9i2UQySuJU=; b=iu/xQmvOYRZuHUBQlJqxss+yN3RyhYkKIoKeTTgqky1B8l3B3RcYmQrhh04ecEikg3 igdEWt79/yFS5X+DdEfgXpuwx1i3qr3JZRlaFCOQykMNQx14kuBK04jdP+HccQVNqIDP vwWkjcsxzshVf3j1Wyptu6xustIZneoh12bB8ir4AXfudQjPL6I1VjtbpllxoACubpB+ SSXGCp1LE2CKcXLl/+HBAngHKTNipgc7t2DXb/9wUJPlAaV7o9TgXc5XxsKqVIPQEJQO okLAM9DE9KLq5x7NxzZz8HaTPNGjT2btMrcKxChefol0sUu8Nu75PG/nuoUnZseGCIHp vGmA== X-Gm-Message-State: ALoCoQm+xaLZEpLBh4iH3zGCbkIth5UfSphFadKImzT6qIZadSqrgrqSoruZV8RLXXu7PPorHKBl MIME-Version: 1.0 X-Received: by 10.42.216.145 with SMTP id hi17mr6430626icb.63.1428704650991; Fri, 10 Apr 2015 15:24:10 -0700 (PDT) Received: by 10.50.45.41 with HTTP; Fri, 10 Apr 2015 15:24:10 -0700 (PDT) In-Reply-To: References: <87iod631nv.fsf@alice.fifthhorseman.net> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <20150409041507.GJ24286@cisco.com> <20150409174603.GX24286@cisco.com> Date: Fri, 10 Apr 2015 15:24:10 -0700 Message-ID: From: Jana Iyengar To: Yoav Nir Content-Type: multipart/alternative; boundary=20cf301cc73c36486c05136639ff Archived-At: Cc: Tom Herbert , Toerless Eckert , Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 22:24:13 -0000 --20cf301cc73c36486c05136639ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This thread seems to gone far afield. To the original question, I still don't see clear value in SPUD open/close bits, but it is clear to me how these can both turn into trivial DoS vectors. Specifically, as I see it even now, - An OPEN bit carries redundant information. - An ACK to the OPEN is a thing apps are likely to do, and we can expect this to be normal behavior. But we don't yet know why a middlebox may need this information to be explicitly present on the wire, or what it may do with it. - A CLOSE bit is unreliable from the middlebox's point of view, since apps may not send it, and unauthenticated CLOSE bits are DoS vectors. If these bits are not authenticated, they are all trivially spoof-able, and they will be exploited for various sorts of DoS attacks. On Thu, Apr 9, 2015 at 1:36 PM, Yoav Nir wrote: > > > On Apr 9, 2015, at 9:40 PM, Tom Herbert wrote: > > > > On Thu, Apr 9, 2015 at 10:46 AM, Toerless Eckert > wrote: > >> Glad you didn't ask how SPUD can solve world peace, because i am > >> still researching that aspect. > >> > >> There is a lot of work going on wit security models of device > deployment, > >> you may want to look at 6LO, 6TISCH, ACE, DICE, ANIMA and there is a > >> lot more outside the IETF. I would see that work as prerequisites > >> to move forward. > >> > >> IN general, i think there is one good and sane device operations metho= d, > >> in IoT which is to NOT upgrade the OS after initial device deployment, > >> but just upgrade/modify applications. And with SPUD, that means you > >> now can upgrade/fix/improve transport layer. > >> > > Well, there's already over a billion smartphones in the world which > > are already regularly updating their OS and this hasn't yet led to > > mass anarchy. You can certainly make avoiding OS updates and avoiding > > OS in general a design point for your products, but this is not a > > relevant design point or requirement for a networking protocol. As I > > said, it's a red herring wrt SPUD. > > There are also over a billion smartphones stuck in an old version of the > OS. Android 2.6 is very popular as is the latest iOS version your phone > supports (lots of iPhone 4 out there, and they=E2=80=99re not getting iOS= 8). > > And don=E2=80=99t get me started on desktop operating systems. By NetApp= =E2=80=99s numbers > just under 17% of desktop and laptop systems are running Windows XP. The > majority are running the already outdated Windows 7. > > And those phones and desktops are things people are always looking at. > Lots of people do upgrade the OS on their phones and computers when given= a > choice. How many people are going to want to upgrade the OS on their > refrigerator, car fuel-injection system, air conditioner, or industrial > sensor? Those things are deep into =E2=80=9Cif it works - don=E2=80=99t f= ix it=E2=80=9D territory. > > Yoav > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --20cf301cc73c36486c05136639ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This thread seems to gone far afield. To the original ques= tion, I still don't see clear value in SPUD open/close bits, but it is = clear to me how these can both turn into trivial DoS vectors. Specifically,= as I see it even now,
- An OPEN bit carries redundant information.
- An ACK to the OPEN is a thing apps are likely to do, and we can ex= pect this to be normal behavior. But we don't yet know why a middlebox = may need this information to be explicitly present on the wire, or what it = may do with it.
- A CLOSE bit is unreliable from the middlebox= 9;s point of view, since apps may not send it, and unauthenticated CLOSE bi= ts are DoS vectors.

If these bits are not authenti= cated, they are all trivially spoof-able, and they will be exploited for va= rious sorts of DoS attacks.

On Thu, Apr 9, 2015 at 1:36 PM, Yoav Nir <ynir.iet= f@gmail.com> wrote:

> On Apr 9, 2015, at 9:40 PM, Tom Herbert <tom@herbertland.com> wrote:
>
> On Thu, Apr 9, 2015 at 10:46 AM, Toerless Eckert <eckert@cisco.com> wrote:
>> Glad you didn't ask how SPUD can solve world peace, because i = am
>> still researching that aspect.
>>
>> There is a lot of work going on wit security models of device depl= oyment,
>> you may want to look at 6LO, 6TISCH, ACE, DICE, ANIMA and there is= a
>> lot more outside the IETF. I would see that work as prerequisites<= br> >> to move forward.
>>
>> IN general, i think there is one good and sane device operations m= ethod,
>> in IoT which is to NOT upgrade the OS after initial device deploym= ent,
>> but just upgrade/modify applications. And with SPUD, that means yo= u
>> now can upgrade/fix/improve transport layer.
>>
> Well, there's already over a billion smartphones in the world whic= h
> are already regularly updating their OS and this hasn't yet led to=
> mass anarchy. You can certainly make avoiding OS updates and avoiding<= br> > OS in general a design point for your products, but this is not a
> relevant design point or requirement for a networking protocol. As I > said, it's a red herring wrt SPUD.

There are also over a billion smartphones stuck in an old version of= the OS. Android 2.6 is very popular as is the latest iOS version your phon= e supports (lots of iPhone 4 out there, and they=E2=80=99re not getting iOS= 8).

And don=E2=80=99t get me started on desktop operating systems. By NetApp=E2= =80=99s numbers just under 17% of desktop and laptop systems are running Wi= ndows XP. The majority are running the already outdated Windows 7.

And those phones and desktops are things people are always looking at. Lots= of people do upgrade the OS on their phones and computers when given a cho= ice. How many people are going to want to upgrade the OS on their refrigera= tor, car fuel-injection system, air conditioner, or industrial sensor? Thos= e things are deep into =E2=80=9Cif it works - don=E2=80=99t fix it=E2=80=9D= territory.

Yoav
_____________________= __________________________
Spud mailing list
Spud@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spud

--20cf301cc73c36486c05136639ff-- From nobody Fri Apr 10 15:25:35 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71ACD1B2DCC for ; Fri, 10 Apr 2015 15:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 xI_T7HlqIZYX for ; Fri, 10 Apr 2015 15:25:28 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 5119A1B2DC9 for ; Fri, 10 Apr 2015 15:25:20 -0700 (PDT) Received: by igblo3 with SMTP id lo3so9294122igb.1 for ; Fri, 10 Apr 2015 15:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=XmWH0wksgz8CC2vjEai1BOvhXexbXcsTX1vj0UTaxa8=; b=kPMrrT/jQ8BwK0v/T+5U/iyzjt752qtnl36wmPzVmdOBmmEKcSBhvK9wcUAKxfsSln csf7TBUiv4E9K8Hwietf5XXguPuwq41CIU7GUEUXQ95ovANmY+gmXcFm45fXwJY5cR4/ E10lHXT1vtLpkaiSDYFUZ59ZZUYgtqyI37caY0veLOvTH0nilgOgwE+KM9DSziqnEMUN 8V6HpbaizfmT/kjYV3a+gV+uxXxB8crxFU+uUk8IsUaveNpYsQUt7+2RYa35Ly18rgcr uvlWVYS1kFIgjVVkeApAvc87bbec4HG0qpN9z1Cprcm7OmNGiNq9mDICIWCAHCw3R7cT Z0zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=XmWH0wksgz8CC2vjEai1BOvhXexbXcsTX1vj0UTaxa8=; b=Ey1p/W8AJd4XQwM13BvuYMptgRyo864/urbkTCDbdte4bdmZsoAuYzvCPKx6tPdoml KP401EI1RmWHpKZVVJzbWk1yXLfn53SBErgLO1l8+DW9GdQfxB4ay+I51p9wxiIt/JoU IkDjFQVKzZAQ3MqddF3YSE1h7gCMFDPykcdZUy7odtSf09ahX51weifAEv5hag+Zqd2R g4zxncyVGgxzewEFq8z7tIlnfk3JMXtzL2kSBtc+EM0qE8331Us9HxlH5pYnlb+avsH4 o/gVYyknUJDhUyHOQlCzbM7ewdCQ0fHOHRvV1q3zHSzSRtfgMqBfDbqcVHP7t3BaTq20 D02g== X-Gm-Message-State: ALoCoQlh8U098Ii7Cd9fKrIrrEHD43BQUmQi3l24LhnHuxbhZayTvBCGDmApnrN4dbhvkIgFPhNx MIME-Version: 1.0 X-Received: by 10.42.216.145 with SMTP id hi17mr6434552icb.63.1428704719815; Fri, 10 Apr 2015 15:25:19 -0700 (PDT) Received: by 10.50.45.41 with HTTP; Fri, 10 Apr 2015 15:25:19 -0700 (PDT) Date: Fri, 10 Apr 2015 15:25:19 -0700 Message-ID: From: Jana Iyengar To: Toerless Eckert Content-Type: multipart/alternative; boundary=20cf301cc73c5058520513663df5 Archived-At: Cc: Tom Herbert , Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: [Spud] SPUD scoping (was Re: SPUD's open/close are unconvincing) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 22:25:31 -0000 --20cf301cc73c5058520513663df5 Content-Type: text/plain; charset=UTF-8 Toerless, PHB, all: One response inline, also because it uncovers something that I want to speak to: > > > > What's missing from SCTP ? > > > > Quite, do we have the opportunity for a quick fix here? If SCTP has > > already done all the necessary design work, can we just bolt that on > > top of UDP in place of IP and declare a quick victory? > > You should talk to the SCTP folks or read the specs. I am not > on top of the details but i think it does a lot of what you ask. > For me, userland eg: SCTP would be a pre-requisite to make a solution like > SPUD successful, not an argument to not do SPOD. See my mail where i > was trying to explain the three layers of the transport stack > as i would like to see it. > I'm quite intimately familiar with SCTP, and what SCTP provides is *not* germane to whether SPUD should happen or not. The point is to allow for UDP-based transports to exist, such as Adobe's RTMFP, FaceTime's UDP-based protocol (whatever that's called), Quake-3's transport protocol, ... if you want to bolt SCTP on top of UDP, that's fine. SPUD should allow you to do that. Architecturally, IMO, the value of SPUD is in bringing some semblance of shared connection-level behaviors and signaling to UDP-based transports, so that (i) middleboxes can make life easier for UDP-based transports, and so that (ii) middleboxes can understand the common design patterns in UDP-based transports so that they can do middleboxy things better. UDP-based transports have existed for quite a while, and continue to be developed and deployed; SPUD can do the right thing of tying them at the waist. IMO, it is extremely important to define a narrow waist though, so that SPUD doesn't ossify the design space atop UDP. UDP is the wild-west right now; bringing order to this space shouldn't result in a strait-jacketing of this space. Conversely, if it seems to strait-jacket this design space, SPUD will likely not take off, simply because the experiments that folks are currently running on UDP that don't fit the SPUD world-view will simply not adopt SPUD. So, in my mind, any effort that seeks to work on enabling UDP-based transports must find and document shared design patterns in existing UDP-based transports, and if absolutely necessary, specify bits to be exposed to the network. There are several things that are behavior and *not* bits on the wire, but these seem to have been dropped in favor of a protocol spec. Things such as: - congestion control for non-TCP transports (we did this for LEDBAT, and discovered how difficult it was to specify congestion control without assuming framing. This is, in general, a difficult but incredibly important exercise.) - loss recovery ideas (how do you provide reliability?) that are untangled from the TCP-ese that they are currently tangled in in both RFCs and in implementations. - best practices on various things that commonly affect UDP-based transports including known NAT behavior, known practices about UDP blocking, UDP rate limiting, etc. It's quite possible I have a different view of what's useful to be done in this space. My concern is that conversations here are rushing headlong into a discussion of a protocol, but if we are talking about an architectural shift -- where UDP-based transports are increasing in number and scope, and where we try to engage middleboxes in protocol design --- it seems to me that our starting questions need to be broader than the specific bits of the SPUD prototype. And our starting conversations need to include currently deployed UDP-based transports. - jana --20cf301cc73c5058520513663df5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Toer= less, PHB, all:

One response inline, also because it uncovers something that I wa= nt to speak to:
=C2=A0
>= > What's missing from SCTP ?
>
> Quite, do we have the opportunity for a quick fix here? If SCTP has > already done all the necessary design work, can we just bolt that on > top of UDP in place of IP and declare a quick victory?

You should talk to the SCTP folks or read the specs. I am not
on top of the details but i think it does a lot of what you ask.
For me, userland eg: SCTP would be a pre-requisite to make a solution like<= br> SPUD successful, not an argument to not do SPOD. See my mail where i
was trying to explain the three layers of the transport stack
as i would like to see it.

I'm quit= e intimately familiar with SCTP, and what SCTP provides is *not* germane to= whether SPUD should happen or not. The point is to allow for UDP-based tra= nsports to exist, such as Adobe's RTMFP, FaceTime's UDP-based proto= col (whatever that's called), Quake-3's transport protocol, ... if = you want to bolt SCTP on top of UDP, that's fine. SPUD should allow you= to do that.

Architecturally, IMO, the value of SP= UD is in bringing some semblance of shared connection-level behaviors and s= ignaling to UDP-based transports, so that (i) middleboxes can make life eas= ier for UDP-based transports, and so that (ii) middleboxes can understand t= he common design patterns in UDP-based transports so that they can do middl= eboxy things better. UDP-based transports have existed for quite a while, a= nd continue to be developed and deployed; SPUD can do the right thing of ty= ing them at the waist.

IMO, it is extremely import= ant to define a narrow waist though, so that SPUD doesn't ossify the de= sign space atop UDP. UDP is the wild-west right now; bringing order to this= space shouldn't result in a strait-jacketing of this space. Conversely= , if it seems to strait-jacket this design space, SPUD will likely not take= off, simply because the experiments that folks are currently running on UD= P that don't fit the SPUD world-view will simply not adopt SPUD.
<= div>
So, in my mind, any effort that seeks to work on enablin= g UDP-based transports must find and document shared design patterns in exi= sting UDP-based transports, and if absolutely necessary, specify bits to be= exposed to the network. There are several things that are behavior and *no= t* bits on the wire, but these seem to have been dropped in favor of a prot= ocol spec. Things such as:
- congestion control for non-TCP trans= ports (we did this for LEDBAT, and discovered how difficult it was to speci= fy congestion control without assuming framing. This is, in general, a diff= icult but incredibly important exercise.)
- loss recovery ideas (= how do you provide reliability?) that are untangled from the TCP-ese that t= hey are currently tangled in in both RFCs and in implementations.
- best practices on various things that commonly affect UDP-based transpor= ts including known NAT behavior, known practices about UDP blocking, UDP ra= te limiting, etc.

It's quite possible I have a different view of what's useful = to be done in this space.=C2=A0My concern is that conversations here= are rushing headlong into a discussion of a protocol, but if we are talkin= g about an architectural shift -- where UDP-based transports are increasing= in number and scope, and where we try to engage middleboxes in protocol de= sign --- it seems to me that our starting questions need to be broader than= the specific bits of the SPUD prototype. And our starting conversations ne= ed to include currently deployed UDP-based transports.

=
- jana
--20cf301cc73c5058520513663df5-- From nobody Fri Apr 10 15:47:23 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8137B1B2DF6 for ; Fri, 10 Apr 2015 15:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 klIoPvsoTk0z for ; Fri, 10 Apr 2015 15:47:19 -0700 (PDT) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (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 54C791B2DF3 for ; Fri, 10 Apr 2015 15:47:19 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so32427908ied.1 for ; Fri, 10 Apr 2015 15:47:18 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=UJRTHDObPTtKvLXCgbaPy9QiVbvThmwx3bvtUP8VyP4=; b=TVHfYOpu+v4wNNm5VUyTaJcbwB4MICz8fcfr/mvY7Ib9ft4aLlSnvkp6oNQnGFpg4n TLPFO5YCXt2j8DkI/7Zg9BlDUs5Quxy3/Gl6lAwpdU7OcaGFmTdXvvNZpgjeQp0SbiJS PJyD6Bng7ae/15CoCo/IdrDJlGm57FRa3XIgjBi0s4mfhmvVZOqQ2yE+p0370akvC9M4 KeCFwJM98DFT68WBlSZU+OYr6NqJuKyMkkSSnjTBkt2TLxRvzK7R9q6OJUAQcnyDThST rzedlmkK0i6fTSWG/9Me4QdqHi5nx9RjIZZ2Dw4tSKCehr+v1bhFlvpvBmcPsKPKEub4 UYcw== X-Gm-Message-State: ALoCoQkCsWd/kzllGimU/pEW28df1H8s4qzRM7UeH1bjNGtzyoz6U83nD10VS9mRYKP6MzpGsk0a MIME-Version: 1.0 X-Received: by 10.107.164.209 with SMTP id d78mr6148836ioj.73.1428706038846; Fri, 10 Apr 2015 15:47:18 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Fri, 10 Apr 2015 15:47:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Apr 2015 15:47:18 -0700 Message-ID: From: Tom Herbert To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Toerless Eckert , Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD scoping (was Re: SPUD's open/close are unconvincing) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 22:47:21 -0000 On Fri, Apr 10, 2015 at 3:25 PM, Jana Iyengar wrote: > Toerless, PHB, all: > > One response inline, also because it uncovers something that I want to speak > to: > > >> >> > > What's missing from SCTP ? >> > >> > Quite, do we have the opportunity for a quick fix here? If SCTP has >> > already done all the necessary design work, can we just bolt that on >> > top of UDP in place of IP and declare a quick victory? >> >> You should talk to the SCTP folks or read the specs. I am not >> on top of the details but i think it does a lot of what you ask. >> For me, userland eg: SCTP would be a pre-requisite to make a solution like >> SPUD successful, not an argument to not do SPOD. See my mail where i >> was trying to explain the three layers of the transport stack >> as i would like to see it. > > > I'm quite intimately familiar with SCTP, and what SCTP provides is *not* > germane to whether SPUD should happen or not. The point is to allow for > UDP-based transports to exist, such as Adobe's RTMFP, FaceTime's UDP-based > protocol (whatever that's called), Quake-3's transport protocol, ... if you > want to bolt SCTP on top of UDP, that's fine. SPUD should allow you to do > that. > > Architecturally, IMO, the value of SPUD is in bringing some semblance of > shared connection-level behaviors and signaling to UDP-based transports, so > that (i) middleboxes can make life easier for UDP-based transports, and so > that (ii) middleboxes can understand the common design patterns in UDP-based > transports so that they can do middleboxy things better. UDP-based > transports have existed for quite a while, and continue to be developed and > deployed; SPUD can do the right thing of tying them at the waist. > > IMO, it is extremely important to define a narrow waist though, so that SPUD > doesn't ossify the design space atop UDP. UDP is the wild-west right now; > bringing order to this space shouldn't result in a strait-jacketing of this > space. Conversely, if it seems to strait-jacket this design space, SPUD will > likely not take off, simply because the experiments that folks are currently > running on UDP that don't fit the SPUD world-view will simply not adopt > SPUD. > > So, in my mind, any effort that seeks to work on enabling UDP-based > transports must find and document shared design patterns in existing > UDP-based transports, and if absolutely necessary, specify bits to be > exposed to the network. There are several things that are behavior and *not* > bits on the wire, but these seem to have been dropped in favor of a protocol > spec. Things such as: > - congestion control for non-TCP transports (we did this for LEDBAT, and > discovered how difficult it was to specify congestion control without > assuming framing. This is, in general, a difficult but incredibly important > exercise.) > - loss recovery ideas (how do you provide reliability?) that are untangled > from the TCP-ese that they are currently tangled in in both RFCs and in > implementations. > - best practices on various things that commonly affect UDP-based transports > including known NAT behavior, known practices about UDP blocking, UDP rate > limiting, etc. > > It's quite possible I have a different view of what's useful to be done in > this space. My concern is that conversations here are rushing headlong into > a discussion of a protocol, but if we are talking about an architectural > shift -- where UDP-based transports are increasing in number and scope, and > where we try to engage middleboxes in protocol design --- it seems to me > that our starting questions need to be broader than the specific bits of the > SPUD prototype. And our starting conversations need to include currently > deployed UDP-based transports. > Jana, I agree with most of what you are saying except for the part about looking at "UDP-based transports". I don't think there is such a thing in the sense that any existing transport protocol can easily be adapted to run over UDP (UDP, after all, is just an envelope). SCTP/UDP for instance, would be a great candidate to run over SPUD if it solves the problems of introducing a supporting a new (non-TCP) IP protocol on the Internet and is a reliable way to get it through stateful firewalls. It seems like the direction should be to identify the minimum information from existing deployed transport protocols that needs to be exposed to the network-- TCP is obviously a primary one to look at. Thanks, Tom > - jana > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Fri Apr 10 18:54:20 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E94A1A877E for ; Fri, 10 Apr 2015 18:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 D5ftFtDdR5f6 for ; Fri, 10 Apr 2015 18:54:17 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BBD1A8702 for ; Fri, 10 Apr 2015 18:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5886; q=dns/txt; s=iport; t=1428717257; x=1429926857; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=NxcP5pBXv0CDPHMbD5sh+y2Np9h2x1RjEV6db0gFHpc=; b=UmwjwvOn6qW6RQ6b1aS/D2wcJ/ch01erg0CWAHEFIR+sJ/vsXbPu27my EZUl5XSd8JqnU+s6jBmaiWcq1s8v46pY4XT5k7s1aYUCLSQw8kY5tNBDF xh9619EAaRGk309Yi8XAl0g9u3Eyoga7AMD06aJcvfVu6qIVk7OU4aFzT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHBQCWfihV/5xdJa1cgwyBLsRrh08CgT06EgEBAQEBAQF9hB8BAQEDATo/BQsLDgoJJQ8FSRMZiAkIzksBAQEBAQEBAQEBAQEBAQEBAQEBARiKLH+EfAeELQWGIYUKi3yDaAGBHY98g0wiggMcgXAeMYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,559,1422921600"; d="scan'208";a="140237850" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 11 Apr 2015 01:54:16 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3B1sFHf012390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2015 01:54:16 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t3B1sFYm008775; Fri, 10 Apr 2015 18:54:15 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t3B1sEVQ008772; Fri, 10 Apr 2015 18:54:14 -0700 Date: Fri, 10 Apr 2015 18:54:14 -0700 From: Toerless Eckert To: Jana Iyengar Message-ID: <20150411015414.GI24286@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Tom Herbert , Phillip Hallam-Baker , Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD scoping (was Re: SPUD's open/close are unconvincing) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 01:54:19 -0000 On Fri, Apr 10, 2015 at 03:25:19PM -0700, Jana Iyengar wrote: > I'm quite intimately familiar with SCTP, and what SCTP provides is *not* > germane to whether SPUD should happen or not. The point is to allow for > UDP-based transports to exist, such as Adobe's RTMFP, FaceTime's UDP-based > protocol (whatever that's called), Quake-3's transport protocol, ... if you > want to bolt SCTP on top of UDP, that's fine. SPUD should allow you to do > that. Right. I was primarily pounding on how SPUD can help proliferate work on reliable transport layer over UDP. But its equally valuable to provide a lightweight "connection layer" for datagram transport protocols like you mention them. So that three layer transport that i dres (UDP+SPUD+Proto) should defnitely be inclusive of datagram and reliable "Proto". > Architecturally, IMO, the value of SPUD is in bringing some semblance of > shared connection-level behaviors and signaling to UDP-based transports, so > that (i) middleboxes can make life easier for UDP-based transports, and so > that (ii) middleboxes can understand the common design patterns in > UDP-based transports so that they can do middleboxy things better. Right, I'd maybe just call it "connection oriented datagram service protocol", but that doesn't include those aspects of it that interact with middleboxes. > UDP-based transports have existed for quite a while, and continue to be > developed and deployed; SPUD can do the right thing of tying them at the > waist. Not quite sure i get that picture. Do i have to loose weight to use SPUD ? ;-)) > IMO, it is extremely important to define a narrow waist though, so that > SPUD doesn't ossify the design space atop UDP. UDP is the wild-west right > now; bringing order to this space shouldn't result in a strait-jacketing of > this space. Conversely, if it seems to strait-jacket this design space, > SPUD will likely not take off, simply because the experiments that folks > are currently running on UDP that don't fit the SPUD world-view will simply > not adopt SPUD. Well... lets see. As a cynical aside: i am not sure your premise is correct. HTML (pre 2.0) was a real protocol for a lot of things put into it, but yet it was done because it did help so much to get through FW. And lo and behold, no 20 years later we have HTML 2.0. SO maybe we just need to make SPUD successfull, however much it sucks, and the rest will resolve itself in time ;-) What SPUD should provide is primarily the minimum necessary and sufficient to get better through future middleboxes. I can think different type of middleboxes may have different degree of requirements, but ultimately, you shouldn't need to have more in SPUD than what those middleboxes want you do do - or what the SPUD application wants them to do. I think extensibility would be good to bake into the design. > So, in my mind, any effort that seeks to work on enabling UDP-based > transports must find and document shared design patterns in existing > UDP-based transports, and if absolutely necessary, specify bits to be > exposed to the network. There are several things that are behavior and > *not* bits on the wire, but these seem to have been dropped in favor of a > protocol spec. Things such as: > - congestion control for non-TCP transports (we did this for LEDBAT, and > discovered how difficult it was to specify congestion control without > assuming framing. This is, in general, a difficult but incredibly important > exercise.) Well... I think SPUD should include elements for common "QoE" interactions with middleboxes. Packet priority, signaling of bandwidth etc. pp. Those would be leveraged by congestion control end-to-end. I don't think that we could define an actual congestion control mechanism into SPUD because work like LEDBAT, RMCAT and all the other stuff going on shows that we do want and need to support a variety of different congestion control mechanisms. > - loss recovery ideas (how do you provide reliability?) that are untangled > from the TCP-ese that they are currently tangled in in both RFCs and in > implementations. Can you give an example ? My pet topic of course are indications of drop-priority at packet level, also because this would nicely match abilities of key transport media like wireless (higher reliabiliy == more bandwidth required for packet because of higher probability for L2 retransmit). > - best practices on various things that commonly affect UDP-based > transports including known NAT behavior, known practices about UDP > blocking, UDP rate limiting, etc. Example ? > It's quite possible I have a different view of what's useful to be done in > this space. My concern is that conversations here are rushing headlong into > a discussion of a protocol, but if we are talking about an architectural > shift -- where UDP-based transports are increasing in number and scope, and > where we try to engage middleboxes in protocol design --- it seems to me > that our starting questions need to be broader than the specific bits of > the SPUD prototype. And our starting conversations need to include > currently deployed UDP-based transports. Imagine you had a nice concept requirement but no ida how you would code it into the actual protocol bits (and how middleboxes should interact with it). In a waterfall process we'd write it down and a year later we discover we can't figure out how to do it, only that we likely wasted a lot of time figuring out its interations in before. So the use of a SPUD prototype protocol that we can bitch about how to modify is IMHO primarily a tool to keep the discussion close to the metal and focussed on deliverying useable code more than long documents. Cheers Toerless > - jana -- --- Toerless Eckert, eckert@cisco.com From nobody Sat Apr 11 00:25:20 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8641AC415 for ; Sat, 11 Apr 2015 00:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NBXnqZT9yuwL for ; Sat, 11 Apr 2015 00:25:18 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993261AC417 for ; Sat, 11 Apr 2015 00:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6104; q=dns/txt; s=iport; t=1428737119; x=1429946719; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=fhTTrMiNt3VOAscCYizcdyyXT69pinLPr33sbj6BMrc=; b=b5ekSe2FH4AytUBYBFB/MCyPUxX5DgW0g/HkQ3I5uTMB6LD9N+jDLKfR 3C66YK/gQ7xCisP5GmfLHWcihnBJQ8JvzvRiaSLzIvbafbrId7b+oSWRG ygb4bb/qdWWkFouiAohQyPNkTQ7mHRX+EgxxzFPa/IyZLtg22VuO6pIAW Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AwCRyyhV/xbLJq1ch0/BTQmHTwKBbRQBAQEBAQEBfYQgAQEEI1UBEAsOCgkWCwICCQMCAQIBRQYNAQcBAYgmt0WWWQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4R8B4JogUUBBJJ2gTOGbIcYjVMig3E8gnQBAQE X-IronPort-AV: E=Sophos;i="5.11,560,1422921600"; d="asc'?scan'208,217";a="444234451" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 11 Apr 2015 07:25:17 +0000 Received: from [10.61.216.216] ([10.61.216.216]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3B7PFWf015409; Sat, 11 Apr 2015 07:25:15 GMT Message-ID: <5528CC5B.4000501@cisco.com> Date: Sat, 11 Apr 2015 09:25:15 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jana Iyengar References: <87iod631nv.fsf@alice.fifthhorseman.net> <55261A99.5090801@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k7amm7WdtAnwbebGcCwOOF6kSXjbQLNP1" Archived-At: Cc: Daniel Kahn Gillmor , "spud@ietf.org" Subject: Re: [Spud] SPUD's open/close are unconvincing X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 07:25:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k7amm7WdtAnwbebGcCwOOF6kSXjbQLNP1 Content-Type: multipart/alternative; boundary="------------020106010109030602060102" This is a multi-part message in MIME format. --------------020106010109030602060102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/11/15 12:20 AM, Jana Iyengar wrote: > Eliot, > > A few responses: > > Open provides an indication that the flow is not a continuation, > that new state should be instantiated, that any old state of the > 5-tuple should be discarded. Opens may flow in either direction, > but may be authorized for only some uses. > > > If used like this, it creates another DoS vector where anyone can > trivially kick someone else's connection off. Huge vast numbers of devices simply look to see if ACK is set, and if not, reject most connections, except for a few. The reason SYN is needed is so that the firewall simply knows that the host will reject communications that begin with something else. > =20 > AFAIK, TCP connections are commonly torn down with an RST (not a FIN), > and not infrequently with silence. I would love to know what the truth > is -- is there any data that I can look at to prove myself wrong? I don't know. But whether one uses RST or FIN is immaterial. The concept is roughly similar in terms of signaling state, except that RST allows for quicker removal of state. > Why would a DoS attacker set the OPEN bit in SPUD if it will thwart > their attack? That would be silly... > =20 If it knows that the end point will simply discard the packet without the OPEN having been seen, it will set it. Eliot --------------020106010109030602060102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 4/11/15 12:20 AM, Jana Iyengar wrote:
Eliot,

A few responses:

Open provides = an indication that the flow is not a continuation, that new state should be instantiated, that any old state of the 5-tuple should be discarded.=C2=A0 Opens may flo= w in either direction, but may be authorized for only some uses.

If used like this, it creates another DoS vector where anyone can trivially kick someone else's connection off.

Huge vast numbers of devices simply look to see if ACK is set, and if not, reject most connections, except for a few.=C2=A0 The reason S= YN is needed is so that the firewall simply knows that the host will reject communications that begin with something else.
=C2=A0
AFAIK, TCP connections are commonly torn down with an RST (not a FIN), and not infrequently with silence. I would love to know what the truth is -- is there any data that I can look at to prove myself wrong?

I don't know.=C2=A0 But whether one uses RST or FIN is immaterial.=C2= =A0 The concept is roughly similar in terms of signaling state, except that RST allows for quicker removal of state.
Why would a DoS attacker set the OPEN bit in SPUD if it will thwart their attack? That would be silly...
=
=C2=A0

If it knows that the end point will simply discard the packet without the OPEN having been seen, it will set it.

Eliot
--------------020106010109030602060102-- --k7amm7WdtAnwbebGcCwOOF6kSXjbQLNP1 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 iQEcBAEBCAAGBQJVKMxcAAoJEIe2a0bZ0nozaEwH/1eYBwY+JQQJPLgVaoNsbL/g l4scBa2Y1peh2zuTpsvNjGQt1Xb+r+HhFJVqN5M73BqhrYcA+YUEJANm67aB2UAb iuVmzZ+Ej+rPJtFAyyAGQsJ4gFb8Ei4QCRAbFgYcVfJE8bO0nOf+l/8mACWkmhlj IaE7wmsEcmMU8bgQKh4Ev8eQORgPYn1w+eaoZHW4dm/5zvhOnzpo2wtmG90rjnhl T2hBWvigkUeHvDatPD/PxcCIk/XAdhy92w0UbgoJI0aIGNoVGvcpKTq9JV1T7gQZ 6IHTD04MYifCg15C1pSzz4HXSjjkAvA6m7bPbO5wWe9WmrnxVt63fyQrJjohkFU= =Ja87 -----END PGP SIGNATURE----- --k7amm7WdtAnwbebGcCwOOF6kSXjbQLNP1-- From nobody Tue Apr 14 04:03:47 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0861A88F4 for ; Tue, 14 Apr 2015 04:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ZwNTH5FUEZ_I for ; Tue, 14 Apr 2015 04:03:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEB31A8901 for ; Tue, 14 Apr 2015 04:03:20 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-e8-552cf3f6f609 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8D.69.28835.6F3FC255; Tue, 14 Apr 2015 13:03:19 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Tue, 14 Apr 2015 13:03:18 +0200 From: Lars Westberg To: "spud@ietf.org" Thread-Topic: "framing for UDP" Thread-Index: AdB2ojygOYQmYmTKS9+tBuj/AuTbYw== Date: Tue, 14 Apr 2015 11:03:17 +0000 Message-ID: <5A0CBBC6F5BA334D94DF4DFCC2674B253CD5C48F@ESESSMB303.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_5A0CBBC6F5BA334D94DF4DFCC2674B253CD5C48FESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje73zzqhBvdKLBZdeMrowOixZMlP pgDGKC6blNSczLLUIn27BK6MTa+eMhes1qjYduw+WwPjU+UuRk4OCQETiVlL3jJD2GISF+6t Z+ti5OIQEjjKKHH0YyszhLOEUWLZ8SfsIFVsAgYSf/qfsYDYIgLKEmvvLAKLCwtISdxcNhkq Li9xffEhZghbT2LOv11sIDaLgKrE/AnTwOp5BXwlzs1fCmYzAm3+fmoNE4jNLCAucevJfCaI iwQkluw5D3WdqMTLx/9YIWwliR8bLrFA1OdL9H34zwIxU1Di5MwnLBMYhWYhGTULSdksJGUQ cQOJ9+fmM0PY2hLLFr6GsvUlNn45y4gsvoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZG YEwc3PLbagfjweeOhxgFOBiVeHgXlOiECrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBMT3w2WXjyAxXk8W7JNUD75+o+JbMuY1f/2dukKTd59z0s4vaeH// vZt9T5j3TTfbFp6eFXax3u8iZ8//9WKFQVSu+bLJMfvnR8/ImfL19Lf6gy9tGtw/3s+QN5rR zNd67XTXVj/bL/kJl8UcXDpKZqTdSE7PCPWb8GnF1+JN1hEVFQqHjaMfKrEUZyQaajEXFScC ADrudNxqAgAA Archived-At: Subject: [Spud] "framing for UDP" X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 11:03:45 -0000 --_000_5A0CBBC6F5BA334D94DF4DFCC2674B253CD5C48FESESSMB303erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, We have prepared a draft on a UDP-based container architecture to transfer = transport protocol components in an end2end UDP-stream. The concept propos= es a standard =93encapsulation=94 to identify/select the used protocol com= ponents rather than having separate specification for different protocols. = The idea is to allow for a more open protocol design where each smaller pr= otocol component can be modified and replaced separately. This end2end component identification/selection has the same semantics as S= PUD (meant to bring information about higher protocol layers in an end2end = header), so in principle SPUD could be used as a protocol for both end2end = transport protocol (component) negotiation and middlebox interception of th= e information about the used components. Is this relevant for the SPUD-work? http://www.ietf.org/internet-drafts/draft-mihaly-tp-flexibility-00.txt http://www.ietf.org/internet-drafts/draft-westberg-tp-compositioning-framew= ork-00.txt -Lars Westberg, Ericsson --_000_5A0CBBC6F5BA334D94DF4DFCC2674B253CD5C48FESESSMB303erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We have prepared a draft= on a UDP-based container architecture to transfer transport protocol compo= nents in an end2end  UDP-stream. The concept proposes a standard =93en= capsulation=94  to identify/select the used protocol components rather than having separate specification for different protoco= ls. The idea is to allow for a more open protocol design where each  s= maller protocol component can be modified and replaced separately.

 =

This end2end component i= dentification/selection has the same semantics as SPUD (meant to bring info= rmation about higher protocol layers in an end2end header), so in principle= SPUD could be used as a protocol for both end2end transport protocol (component) negotiation and middlebox inte= rception of the information about the used components.

 =

Is this relevant for the= SPUD-work?

 =

http://www.ietf.org/internet-drafts/draft-mi= haly-tp-flexibility-00.txt

http://www.ietf.org/internet-= drafts/draft-westberg-tp-compositioning-framework-00.txt

 =

-Lars Westberg, Ericsson=

--_000_5A0CBBC6F5BA334D94DF4DFCC2674B253CD5C48FESESSMB303erics_-- From nobody Tue Apr 14 06:27:11 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B161A9131 for ; Tue, 14 Apr 2015 06:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 q_vI6QywNkZE for ; Tue, 14 Apr 2015 06:27:06 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA6C1A912F for ; Tue, 14 Apr 2015 06:27:06 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 6DDAC1A00E5 for ; Tue, 14 Apr 2015 15:27:05 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_99D39EF5-A626-4222-928D-304213C6C338"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 14 Apr 2015 15:27:05 +0200 Message-Id: To: spud@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Spud] questions we need a prototype for X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:27:09 -0000 --Apple-Mail=_99D39EF5-A626-4222-928D-304213C6C338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, all, Following a discussion of the BoF proponents and chairs, we wanted to = address the fact that many of the concerns raised at the BoF focused on = the prototype itself: its current lack of anything that looks like = security, the danger of it becoming The Spud Protocol, etc... So we = thought it would be useful to ask, why do we want a prototype? The discussion on this list of the threat models a substrate protocol = must face has been useful, as have the discussions on what might be = useful to expose -- it's clear even among people who think something = like SPUD is a good idea that we have somewhat different visions and = assumptions about this, and these discussions can get us closer to = consensus on these questions. But we think the most direct way to answer = these questions is to actually put packets on the MAC layer of your = choice and see what happens. Hence a prototype. The first few questions we want answers to seem to be the following: - =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8BWhat current = transport-and-payload-inspecting-middlebox features can be replaced by = the selective exposure of which data by the endpoints when the = application and transport information is encrypted, and we presume = protection against MITM and cleartext fallback? - What declarations (from applications, and from the path) are most = useful from the application's point of view? - What declarations (from applications, and potentially other path = elements) are most useful from the point of view of devices on path? - What are the incentives to deploy on both sides? - What kinds of cooperation can we engender in an untrusted environment = composed of path and application? - What are the implicit trust relationships between endpoints and = on-path devices now, and can making these explicit improve cooperation = at all? - Are explicit trust relationships even possible without significant = latency, management overhead, and other costs? - Are there mitigations for attacks on that cooperation? =46rom there we'll need to answer questions about the abstract = interfaces among the layers and interlayers, but these "how" questions = are a bit more fluid than the "what" questions. The = http://github.com/iptube/SPUDlib is the start of one codebase we can use = to set up experiments to try to answer these questions. My question to = the list: what other questions can experimentation help answer? Thanks, cheers, Brian --Apple-Mail=_99D39EF5-A626-4222-928D-304213C6C338 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 iQEcBAEBCgAGBQJVLRWpAAoJENt3nsOmbNJcnb0H/jqErigXo0d7YmII9bmbx5v+ MdEaEd+Vv8Z9NZRmG3T1mzcCvGWJWAekhVoWvqkhspHCTbKAk5PoeNY4PY7aeXD0 SpOqVvGf+LPRShs/Grrxu5m8PFujXUuHquDRVsHKEg80c/JF9gMwb6pB2Tf/R+o1 3fieiY6tN+BFS00Ruph0gHhyC+hR84f32DFjpmu/6BE4LCdpBcUW1K6eQI5a0NSJ NXmt/SSJ20ataEVU/X8GY2ERy4bGvbmsUHerDM0Ns6Dq3yP6c+SVSuIV+0tvmLIy 6RlXOggWSM8x9D/16iA/ypk6eR9gx3Rx6MYZCRXHLCbDTb+pZotRgxc4Z/3YDBg= =yQEm -----END PGP SIGNATURE----- --Apple-Mail=_99D39EF5-A626-4222-928D-304213C6C338-- From nobody Fri Apr 24 09:16:34 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C57E1B3717 for ; Fri, 24 Apr 2015 09:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 pgEiG1BibI0A for ; Fri, 24 Apr 2015 09:16:31 -0700 (PDT) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (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 14DB81B3719 for ; Fri, 24 Apr 2015 09:16:31 -0700 (PDT) Received: by iejt8 with SMTP id t8so87157329iej.2 for ; Fri, 24 Apr 2015 09:16:29 -0700 (PDT) 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:date :message-id:subject:from:to:content-type; bh=VC5k5/QzJeYVonyEcA2rqC5DjbxAVToupHsThj9rJwM=; b=A8/p/TcsN0Dw2p+iR60BZuDn9SfBhtUWXVj/OGNybkUTDUlkLEf5fhzjLlaTq6KDCQ Qa7rOpkR8OURuhkuEzzC8VPXt0SM6hG+JH2/3YfHcs52/7fOLKveZ8l2NDpqVaY8nE+P V6tgqFhSFq4+pIQggqU2EMpRID7H4KpEt2mgJkrvUlZhKxavjAkzuVOeh2HbJ4+rgC4o J94oPns4Zk1d7+4jH4YRwmMteLmXfZtjf8vugMTwGnaFET7gig4zdqu/BLZeTKnz5zDr lOGcJdJMIY38ejFw0W51HWVXlKv3hykHx1wGVLhVzNd6k0iI/praEyhdM57L7ut3t+BV iGGw== X-Gm-Message-State: ALoCoQnJW0xAwsm05An6LgjuP7P3oJXUTUNdNZ/6wX1ItYZhtO/6COXA/gPATkJL9cT8sdN1835y MIME-Version: 1.0 X-Received: by 10.107.130.165 with SMTP id m37mr1029008ioi.62.1429892189428; Fri, 24 Apr 2015 09:16:29 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Fri, 24 Apr 2015 09:16:29 -0700 (PDT) In-Reply-To: <20150424154144.17864.82671.idtracker@ietfa.amsl.com> References: <20150424154144.17864.82671.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 09:16:29 -0700 Message-ID: From: Tom Herbert To: tsvwg@ietf.org, spud@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Spud] Fwd: New Version Notification for draft-herbert-udp-magic-numbers-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:16:32 -0000 Hello, This draft generalizes the concept of magic numbers in UDP payloads like in the SPUD protocol prototype. These are 64 bit constants that should allow middleboxes to correctly identify the type of a UDP payload with high confidence. This would be applicable with several UDP encapsulated protocols that are of interest to middleboxes to parse. Posting to tsvwg and spud lists. Thanks, Tom ---------- Forwarded message ---------- From: Date: Fri, Apr 24, 2015 at 8:41 AM Subject: New Version Notification for draft-herbert-udp-magic-numbers-00.txt To: Tom Herbert , Lucy Yong A new version of I-D, draft-herbert-udp-magic-numbers-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-udp-magic-numbers Revision: 00 Title: UDP Magic Numbers Document date: 2015-04-24 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-herbert-udp-magic-numbers-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-udp-magic-numbers/ Htmlized: http://tools.ietf.org/html/draft-herbert-udp-magic-numbers-00 Abstract: This specification defines magic numbers in UDP which allow a node to determine or confirm the protocol contained in a UDP payload. This is primarily applicable for encapsulation and transport protocols encapsulated within UDP where intermediate devices, such as middle boxes, need to parse these protocols for providing service. Magic numbers can also be used to multiplex different UDP encapsulated protocols over the same UDP port. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat