From nobody Thu Jun 4 09:30:10 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 C9DFA1A90AC for ; Thu, 4 Jun 2015 09:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 nuHZ82XLRluo for ; Thu, 4 Jun 2015 09:30:03 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCD81A9155 for ; Thu, 4 Jun 2015 09:28:38 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-4e-55707cb44790 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FF.53.04401.4BC70755; Thu, 4 Jun 2015 18:28:36 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.142]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Thu, 4 Jun 2015 18:28:36 +0200 From: Szilveszter Nadas To: "spud@ietf.org" Thread-Topic: SPUD Scope? Thread-Index: AdCe42kWUfK3mg2YQc2lRPihacOmIw== Date: Thu, 4 Jun 2015 16:28:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23D47A3EESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre6WmoJQg0mfZS0WXXjK6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK4vDawFez0r1j3/xdLA2GLXxcjJISFgIvHn52c2CFtM4sK9 9UA2F4eQwFFGibYPa1kgnMWMEs8uzWAGqWITsJBoWLkZrENEQFli7Z1F7F2MHBzCAiISN1v9 IcKSEn8XNbFD2HoSf88fYwSxWQRUJF5dvMMCYvMK+Eo8n/4PrIYRaPH3U2uYQGxmAXGJW0/m M0EcJCCxZM95ZghbVOLl43+sELaixM6z7cwQ9fkS//begpopKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQT IzAmDm75rbqD8fIbx0OMAhyMSjy8CS/zQ4VYE8uKK3MPMUpzsCiJ887YnBcqJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgVGqsCvvF3tKYtLkBTOOzvbNXl13++G2Ezla7NOsK+WD/fyqmj8d Xzk/+WPHOvt7Ck8Lg5efXeA6dxu7vp5hs+uCtblPDzm4TH4ifMmJPyZ4q+s23qrDbHohqlP6 c7YW93sw2sgs5u16MvnPdbPNX+M43Q4Esj2KN9oj9YdFk2fNx77Vt3XlZJRYijMSDbWYi4oT AdmBG8FqAgAA Archived-At: Subject: [Spud] SPUD Scope? 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, 04 Jun 2015 16:30:10 -0000 --_000_EA4C43BE752A194597B002779DF69BAE23D47A3EESESSMB303erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I browsed through the mails since last ietf the other day, and I have seen = quite big variety in the scope of SPUD in the different mails. The rage looked like this to me on a high level: a) only start/stop, hide everything in DTLS b) Some declarative, safe to ignore, trust but verify markings are OK, but = it shall be minimized. c) "common, middlebox friendly connection/packet signaling layer", extensib= ility, any communication and behavior is OK as long as it is explicit. I am personally closest to group c), still I understand that this is far fr= om the average view and that it would be pretty hard to reach a consensus r= egarding this. I think that it is very hard to "replace DPI" with easy to v= erify info (assuming encrypted payload) and with declarations with very lig= ht consequences. One can argue that middleboxes shall never be able to have= that detailed knowledge ever again, still if we embrace the role of middle= boxes we probably need more than a) or b). I completely agree that all kind of signaling shall be safe to ignore and i= n a normal case ignoring a signal should not result in denial of the servic= e but rather result in some kind of default behavior. I also think that si= gnaling shall not result on delayed start of the connection (usually it is = enough to change handling later on, no real reason to delay the start) However I do not really see problems with one of the end-point accepting an= offer of a middlebox and communicating with the middlebox with a proprieta= ry vocabulary. SPUD is clearly a good way to offer these improvements to en= d-hosts. Whether the follow up communication is using SPUD as a sub-transpo= rt for the signaling conversation or not is a question. Also this communica= tion (when accepted) might have consequences, e.g. some change in charging.= Obviously some kind of security solution is needed to authenticate the mid= dlebox and the end-point, which is far from trivial. At the same time even with the above assumptions, it is not quite clear how= something like this can happen. I really like the philosophy of the "Tussle in Cyberspace" article. Things = like "Do not design so as to dictate the outcome". Also the part about "Int= erfaces of tussle" and their "properties": "Visible exchange of value", "Ex= posure of cost of choice", "Visibility (or not) of choices made" and "Tools= to resolve and isolate faults and failures". I think that if we want to co= operate with middleboxes these are very good guiding principles. I also thi= nk that many of us are actually biased towards trying to dictate the outcom= e. If we provide possibility to achieve a functionality in an explicit way = is not it better than making network vendors to invent their own not so tra= nsparent solutions for the same? Assuming something like c) is not happening in SPUD where do you think it c= ould/should happen? Cheers, Sz. --_000_EA4C43BE752A194597B002779DF69BAE23D47A3EESESSMB303erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I browsed through the mails since last ietf the othe= r day, and I have seen quite big variety in the scope of SPUD in the differ= ent mails.

 

The rage looked like this to me on a high level:

a) only start/stop, hide everything in DTLS

b) Some declarative, safe to ignore, trust but verif= y markings are OK, but it shall be minimized.

c) “common, middlebox friendly connection/pack= et signaling layer”, extensibility, any communication and behavior is= OK as long as it is explicit.

 

I am personally closest to group c), still I underst= and that this is far from the average view and that it would be pretty hard= to reach a consensus regarding this. I think that it is very hard to ̶= 0;replace DPI” with easy to verify info (assuming encrypted payload) and with declarations with very light consequ= ences. One can argue that middleboxes shall never be able to have that deta= iled knowledge ever again, still if we embrace the role of middleboxes we p= robably need more than a) or b).

 

I completely agree that all kind of signaling shall = be safe to ignore and in a normal case ignoring a signal should not result = in denial of the service but rather result in some kind of default behavior= .  I also think that signaling shall not result on delayed start of the connection (usually it is enough to cha= nge handling later on, no real reason to delay the start)

 

However I do not really see problems with one of the= end-point accepting an offer of a middlebox and communicating with the mid= dlebox with a proprietary vocabulary. SPUD is clearly a good way to offer t= hese improvements to end-hosts. Whether the follow up communication is using SPUD as a sub-transport for the signa= ling conversation or not is a question. Also this communication (when accep= ted) might have consequences, e.g. some change in charging. Obviously some = kind of security solution is needed to authenticate the middlebox and the end-point, which is far from trivial= .

 

At the same time even with the above assumptions, it= is not quite clear how something like this can happen.

 

I really like the philosophy of the “Tussle in= Cyberspace” article. Things like “Do not design so as to dicta= te the outcome”. Also the part about “Interfaces of tussle̶= 1; and their “properties”: “Visible exchange of valueR= 21;, “Exposure of cost of choice”, “Visibility (or not) of choices made” and &#= 8220;Tools to resolve and isolate faults and failures”. I think that = if we want to cooperate with middleboxes these are very good guiding princi= ples. I also think that many of us are actually biased towards trying to dictate the outcome. If we provide possibility to achieve a func= tionality in an explicit way is not it better than making network vendors t= o invent their own not so transparent solutions for the same?

 

Assuming something like c) is not happening in SPUD = where do you think it could/should happen?

 

Cheers,

Sz.

 

 

 

 

 

 

 

 

 

--_000_EA4C43BE752A194597B002779DF69BAE23D47A3EESESSMB303erics_-- From nobody Thu Jun 4 09:36: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 203C41A905A for ; Thu, 4 Jun 2015 09:36:11 -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 M2-oQoXcQWz9 for ; Thu, 4 Jun 2015 09:36:10 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427711A90A0 for ; Thu, 4 Jun 2015 09:36:09 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-49-55707e77e0a3 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 59.52.17665.77E70755; Thu, 4 Jun 2015 18:36:07 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.142]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Thu, 4 Jun 2015 18:36:06 +0200 From: Szilveszter Nadas To: "spud@ietf.org" Thread-Topic: IETF 93 Thread-Index: AdCe49ua0rBTylZNQTqhOqFtvs+IMA== Date: Thu, 4 Jun 2015 16:36:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23D47A9CESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvrW55XUGowbJXqhaLLjxldGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoH7M5gLNkhUfDv6iamBcbVoFyMnh4SAicTceasZIWwxiQv3 1rN1MXJxCAkcZZQ4+eUYE4SzmFHiROd+FpAqNgELiYaVm9lAbBEBZYm1dxaxg9jCAgISPzdO YIWIi0pMWzMFyOYAsvUklh4qBwmzCKhITHi5EqyVV8BXouvhIyYQmxFo8fdTa8BsZgFxiVtP 5jNBHCQgsWTPeWYIW1Ti5eN/rBC2osTOs+3MEPX5Eo+mnYWaKShxcuYTlgmMQrOQjJqFpGwW kjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilG0OLW4ODfdyFgvtSgzubg4P08vL7Vk EyMwJg5u+a27g3H1a8dDjAIcjEo8vAkv80OFWBPLiitzDzFKc7AoifPO2JwXKiSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoGx//23+Zu1UrjubNs+PfKxtPWmCPb/VwzV396cq/L0SNIfnzc9 J+Wf+Z+7PXWxXcgVJiHnmQnhj889sF3NM9V5joGN15yTN53Wxl8PMGl8euLU7KnmFpVvLnx/ bvvA7r5uxXTuvRydSuttuGMnerBru/+RMby/QkL6mPPrXR8Pif22rJmg4VFzUImlOCPRUIu5 qDgRAIRXXBhqAgAA Archived-At: Subject: [Spud] IETF 93 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, 04 Jun 2015 16:36:11 -0000 --_000_EA4C43BE752A194597B002779DF69BAE23D47A9CESESSMB303erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Any the plans for SPUD at IETF 93? One more non-wg forming BoF, or prototyp= e protocol BoF with limited scope, or? I assume that it would be pretty hard to agree in a charter for the "big sc= ope" at the moment (see my previous mail). Still I might be wrong. Also the= re were voices proposing starting a smaller scoped WG developing a prototyp= e protocol. Cheers, Szilveszter --_000_EA4C43BE752A194597B002779DF69BAE23D47A9CESESSMB303erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Any the plans for SPUD at IETF 93? One more non-wg f= orming BoF, or prototype protocol BoF with limited scope, or?

 

I assume that it would be pretty hard to agree in a = charter for the “big scope” at the moment (see my previous mail= ). Still I might be wrong. Also there were voices proposing starting a smal= ler scoped WG developing a prototype protocol.

 

Cheers,

Szilveszter

--_000_EA4C43BE752A194597B002779DF69BAE23D47A9CESESSMB303erics_-- From nobody Thu Jun 4 09:56: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 A77EF1A005F for ; Thu, 4 Jun 2015 09:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 Ehk3eaSIxiC1 for ; Thu, 4 Jun 2015 09:56:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9660E1A005B for ; Thu, 4 Jun 2015 09:56:33 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-69-5570833fb8dc Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.16.04401.F3380755; Thu, 4 Jun 2015 18:56:31 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.142]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Thu, 4 Jun 2015 18:56:31 +0200 From: Szilveszter Nadas To: Brian Trammell Thread-Topic: [Spud] [Stackevo] New Version Notification for draft-trammell-stackevo-newtea-00.txt Thread-Index: AQHQXRIfIOSnar52wEmw0PZ4zeI0F50ZeIyAgIOZ9eA= Date: Thu, 4 Jun 2015 16:56:29 +0000 Message-ID: References: <20150309174102.19512.93730.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvra59c0GowfxVahYbW96xWSy68JTR YsXjn+wOzB63rr5k9liy5CeTx5P9M1kCmKO4bFJSczLLUov07RK4Mh5NWcJS8Im54nXbNNYG xifMXYycHBICJhJtp+ezQthiEhfurWfrYuTiEBI4yijx/90PVghnMaPEhEUQHWwCFhINKzez gdgiAqoS3Y2X2EFsZgEviT8b+phAbGGBZIldV7ezQtSkSJz58hqohgPItpJ42M4LEmYRUJGY tW8ZWDmvgK/E+p6JTBC7djJJHNm0C2wXp0CgxPTOFrAiRqDrvp9awwSxS1zi1pP5TBBXC0gs 2XMe6htRiZeP/0F9oyix82w7M8heZgFNifW79CFaFSWmdD9kh9grKHFy5hOWCYxis5BMnYXQ MQtJxywkHQsYWVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbUwS2/VXcwXn7jeIhRgINR iYc34WV+qBBrYllxZe4hRmkOFiVx3hmb80KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MPIH awneFfIQzb/CvJWXe8mG0Fre0nsrfh2PXVRT8njdvA7hb1Gr07I/ij++pdfl8+jfq9q7zyMS nD0u/shIev/mep7fma/KvW83vXnzTmbVwa2LeTfdd42XfSGyqOSAiqHEN4mEgEsTWW+2NGpL xmUcv7BnQnVE9NOJ8/yFGjWmewbz/13oH6/EUpyRaKjFXFScCADtr0Z0iQIAAA== Archived-At: Cc: "stackevo@iab.org" , "spud@ietf.org" Subject: Re: [Spud] [Stackevo] New Version Notification for draft-trammell-stackevo-newtea-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: Thu, 04 Jun 2015 16:56:34 -0000 SGkgQnJpYW4sDQoNCkZvbGxvd2luZyB1cCBteSB0aGlua2luZyBpbiB0aGUgU1BVRCBzY29wZSBt YWlsLCBhIHF1ZXN0aW9uLCB0byB2ZXJzaW9uLTAxOiANCg0KV2hhdCBkbyB5b3UgdGhpbmsgYWJv dXQgc29tZXRoaW5nIGxpa2UgdGhpcyBhcyBhbiBvcHRpb24gZm9yIDUuMzogYW4gZXhwbGljaXQs IHNhZmUgdG8gaWdub3JlIG1hcmtpbmcgd2hlcmUgaXQgaXMgcG9zc2libGUgdG8gZXN0YWJsaXNo IHRydXN0IHJlbGF0aW9uc2hpcCBhbmQgbm90LWlnbm9yZWQgbWFya2luZ3MgbWF5IGhhdmUgcmVw bHkgYW5kIGNvbnNlcXVlbmNlcz8gKGUuZy4g4oCcRXhwb3N1cmUgb2YgY29zdCBvZiBjaG9pY2Xi gJ0pDQoNCkNoZWVycywNClN6Lg0K From nobody Thu Jun 4 12:25:22 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 8B6301A8978 for ; Thu, 4 Jun 2015 12:25:21 -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 xX9dtj1HSCc6 for ; Thu, 4 Jun 2015 12:25:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2259C1A8977 for ; Thu, 4 Jun 2015 12:25:19 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 988E9F984; Thu, 4 Jun 2015 15:25:14 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 4658A20358; Thu, 4 Jun 2015 15:24:52 -0400 (EDT) From: Daniel Kahn Gillmor To: Szilveszter Nadas , "spud\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 04 Jun 2015 15:24:52 -0400 Message-ID: <87h9qn1dkr.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Spud] SPUD Scope? 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, 04 Jun 2015 19:25:21 -0000 On Thu 2015-06-04 12:28:34 -0400, Szilveszter Nadas wrote: > The rage looked like this to me on a high level: > > a) only start/stop, hide everything in DTLS > > b) Some declarative, safe to ignore, trust but verify markings are OK, > but it shall be minimized. > > c) "common, middlebox friendly connection/packet signaling layer", > extensibility, any communication and behavior is OK as long as it is > explicit. [...] > However I do not really see problems with one of the end-point > accepting an offer of a middlebox and communicating with the middlebox > with a proprietary vocabulary. SPUD is clearly a good way to offer > these improvements to end-hosts. Whether the follow up communication > is using SPUD as a sub-transport for the signaling conversation or not > is a question. Also this communication (when accepted) might have > consequences, e.g. some change in charging. Obviously some kind of > security solution is needed to authenticate the middlebox and the > end-point, which is far from trivial. This far-from-trivial authentication mechanism, combined with the UI/UX concern about helping people to understand exactly who they are leaking their metadata to, presents a really serious obstacle to deploying something like this in a way that is safe for end users. We need to be *reducing* the amount of metadata that our protocols leak, not providing new channels to leak more of it. > If we provide possibility to achieve a functionality in an explicit > way is not it better than making network vendors to invent their own > not so transparent solutions for the same? We can explicitly discourage network vendors from trying to coax arbitrary metadata out of the traffic that passes across their network. While there are certainly some network vendors that want to do this for purely benevolent reasons, there are far too many middleboxes that would do this for malicious reasons, and there is no clear way that a real-world user can be expected to tell the two apart. Even if the users *could* distinguish "good" middleboxes from "bad" ones (of course, different perspectives means different users will not agree about who is "good" and who is "bad"), there are circumstances where the user has only one network path available to them. Providing arbitrarily-sophisticated metadata-leakage mechanisms provides a way for that network operator to (in an IETF-blessed fashion) demand arbitrary metadata from the user as a precondition to the use of the network. I think that's not something the IETF should be supporting. > Assuming something like c) is not happening in SPUD where do you think > it could/should happen? I don't think something like (c) is a good idea. let's try to keep the smarts (and the knowledge of both content and metadata) at the edges of the network, and avoid blessing mechanisms that facilitate centralized surveillance. Regards, --dkg From nobody Thu Jun 4 12:34:08 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 AE5671A8AD9 for ; Thu, 4 Jun 2015 12:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 QmNfFo6U5nre for ; Thu, 4 Jun 2015 12:34:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427011A8A99 for ; Thu, 4 Jun 2015 12:34:06 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 4 Jun 2015 19:34:05 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0172.012; Thu, 4 Jun 2015 19:34:05 +0000 From: Christian Huitema To: Daniel Kahn Gillmor , Szilveszter Nadas , "spud@ietf.org" Thread-Topic: [Spud] SPUD Scope? Thread-Index: AdCe42kWUfK3mg2YQc2lRPihacOmIwAGLggAAAAYmuA= Date: Thu, 4 Jun 2015 19:34:05 +0000 Message-ID: References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> In-Reply-To: <87h9qn1dkr.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 3:sAEST88yJ8GO5U2eJn2Xzjuxycku8P38jRORThvV7YQGYjTLTk21TMiBWOTcdlMoDz/NcIuddyCzh+tzHaz997cjJtgEALnADScAeZqV96Du6cdtNcgiZpmkAIDq31khA+P5EHM/yCrRx/t950TO4A==; 10:DZXQUotNiemOLKexqzOgLSR3XDZuAYS/KVmeDDaVwjrt2A+Qc2QdHo2zZ+OVjULWhhKMSgEegxcPWiDTu56ehe5qZs4M+SGN/y7S0W5gl20=; 6:x31Vo+0YWsz2Gd8Fgs1agel9sI61SAzY3DC4xok84/h/BSbbafza0en65weYLEmZ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(51704005)(24454002)(189002)(377454003)(199003)(33656002)(106356001)(99286002)(50986999)(54356999)(5001830100001)(76176999)(105586002)(189998001)(4001540100001)(2900100001)(5002640100001)(2950100001)(92566002)(5001860100001)(19580405001)(5001960100002)(107886002)(101416001)(86612001)(5001770100001)(74316001)(122556002)(46102003)(68736005)(64706001)(97736004)(86362001)(2501003)(2656002)(81156007)(76576001)(77156002)(40100003)(19580395003)(87936001)(62966003)(102836002)(77096005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2015 19:34:05.2539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Subject: Re: [Spud] SPUD Scope? 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, 04 Jun 2015 19:34:07 -0000 On Thursday, June 4, 2015 12:25 PM, Daniel Kahn Gillmor wrote: > To: Szilveszter Nadas; spud@ietf.org > Subject: Re: [Spud] SPUD Scope? >=20 > On Thu 2015-06-04 12:28:34 -0400, Szilveszter Nadas wrote: >=20 > > The rage looked like this to me on a high level: > > > > a) only start/stop, hide everything in DTLS > > > > b) Some declarative, safe to ignore, trust but verify markings are OK, > > but it shall be minimized. > > > > c) "common, middlebox friendly connection/packet signaling layer", > > extensibility, any communication and behavior is OK as long as it is > > explicit. >=20 > [...] > > This far-from-trivial authentication mechanism, combined with the UI/UX > concern about helping people to understand exactly who they are leaking t= heir > metadata to, presents a really serious obstacle to deploying something li= ke this > in a way that is safe for end users. Absolutely. This might only work if the client, server, and middleboxes inc= entives are well aligned. That may be the case for some basic QOS-type para= meters, which is very much what (b) should be about.=20 > ... > > I don't think something like (c) is a good idea. let's try to keep the s= marts (and > the knowledge of both content and metadata) at the edges of the network, = and > avoid blessing mechanisms that facilitate centralized surveillance. And a variety of security issues. The unauthenticated data channel is subje= ct to spoofing, which enables a variety of packet injection attacks.=20 -- Christian Huitema From nobody Fri Jun 5 03:37:59 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 BE7121A005C for ; Fri, 5 Jun 2015 03:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J2-CUMaCPx1F for ; Fri, 5 Jun 2015 03:37:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2474D1A1A5A for ; Fri, 5 Jun 2015 03:37:55 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-0d-55717c02eb80 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 20.BB.17665.20C71755; Fri, 5 Jun 2015 12:37:54 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.142]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Fri, 5 Jun 2015 12:37:53 +0200 From: Szilveszter Nadas To: Christian Huitema , Daniel Kahn Gillmor , "spud@ietf.org" Thread-Topic: [Spud] SPUD Scope? Thread-Index: AdCe42kWUfK3mg2YQc2lRPihacOmIwAB/SYAAABSZ4AAIPnEsA== Date: Fri, 5 Jun 2015 10:37:53 +0000 Message-ID: References: <87h9qn1dkr.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: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvrS5TTWGowfMGEYvW7s9MFk2f+xgt Fl14yujA7HG2u53VY8mSn0werTv+sgcwR3HZpKTmZJalFunbJXBlvPjHVnBBueLpj3vMDYwX ZboYOTkkBEwkblw/yQRhi0lcuLeerYuRi0NI4CijxJlfs6GcxYwSq1tAMpwcbAIWEg0rN4PZ IgK1EksOb2AGsYUF5CX+b97IDhFXkPgzpQ+ohgPIdpI4eUgCJMwioCJx6cIRsGW8Ar4SG1/N Y4aYf55R4vr792BzOAUSJTZM/cgKYjMCXfT91BqwBmYBcYlbT+ZDXSogsWTPeWYIW1Ti5eN/ rBC2osTV6cuh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKK UbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzB2Dm75rbuDcfVrx0OMAhyMSjy8D6wKQ4VYE8uK K3MPMUpzsCiJ887YnBcqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdEtYe68FW0r/a8o+69k ntIiLNbJf1h7w522T4ziR+uudAcrzmb6dsZf+8mdon1+RjypKVsWvPl/7k22+6r/LHnTTc6o Xg84VZvJyxu2aqbq+ZnLl+/utVgiFy5W7VxxwOxl58e/JwweLQxkEfFpvjx1mmn62VrnKpty lmuGDm9yT/dtZ+D8cFuJpTgj0VCLuag4EQCKxoPrfgIAAA== Archived-At: Subject: Re: [Spud] SPUD Scope? 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, 05 Jun 2015 10:37:58 -0000 Hi, My concern is whether the whole SPUD exercise is worth the effort without e= xtensibility. Assume that we can agree in a minimal set for b). What if in = a few years' time we realize that we need more? Have not we already ossifie= d the middlebox layer? My vision is that SPUD shall allow both Transport Pr= otocol evolution and Middlebox Cooperation evolution in the same flexible w= ay. :) The goal in my mind if to not ossify transport and not ossify the co= operation functionality.=20 Also is not b) + extensibility =3D c)? Or is there more in c), which is of = concern? About "metadata that our protocols leak", I completely agree that protocols= should minimize this leaking. I think that explicit conversation is not le= aking though and hopefully also discourages the middlebox owners to try to = look into the protocol data itself. Any device/firmware/Operating System/app still have and will have ways to l= eak whatever it wants, just by not allowing extensibility in SPUD we cannot= stop it. At the same time extensible SPUD can be an engine for "good" coop= eration. I believe we can potentially gain more than we lose. The only way = to stop leaking is to have a "purging proxy", but even that proxy would hav= e pretty hard time to remove all unwanted interactions. Also there are plac= es where you simply cannot place a purging proxy e.g. between your access d= evice and the ISP/mobile operator middlebox. About "keeping the smarts at the edge" the IAB program at least includes a = goal to "(2) Improving path transparency in the presence of firewalls and m= iddleboxes: guidelines for the detection of and cooperation with these devi= ces to evolve away from present limitations on which protocols can be used = across network boundaries, in order to facilitate innovation in transport p= rotocol development. ". In a sense it means for me to embrace middlebox fun= ctionality, but make it much more explicit. I think that these functions ar= e important to keep our networks working, but I agree that it has to be muc= h more explicit than in the past. But limiting it looks like a way to keep = it in the grey. I agree that security of the metadata layer will be often equally important= than the security of user content. I am not quite sure whether it could/sh= ould be handled in SPUD or whether SPUD shall "only" allow secure metadata = conversions as a substrate.=20 About the UI/UX concern. This is definitely an issue and not an easy one to= solve. Trust chains, delegation of trust, market apps controlling app righ= ts are pieces of the puzzle to solve this. I think it is possible to find a= solution for this with a good balance of ease of use and control.=20 Sz. -----Original Message----- From: Christian Huitema [mailto:huitema@microsoft.com]=20 Sent: Thursday, June 04, 2015 21:34 To: Daniel Kahn Gillmor; Szilveszter Nadas; spud@ietf.org Subject: RE: [Spud] SPUD Scope? On Thursday, June 4, 2015 12:25 PM, Daniel Kahn Gillmor wrote: > To: Szilveszter Nadas; spud@ietf.org > Subject: Re: [Spud] SPUD Scope? >=20 > On Thu 2015-06-04 12:28:34 -0400, Szilveszter Nadas wrote: >=20 > > The rage looked like this to me on a high level: > > > > a) only start/stop, hide everything in DTLS > > > > b) Some declarative, safe to ignore, trust but verify markings are=20 > > OK, but it shall be minimized. > > > > c) "common, middlebox friendly connection/packet signaling layer",=20 > > extensibility, any communication and behavior is OK as long as it is=20 > > explicit. >=20 > [...] > > This far-from-trivial authentication mechanism, combined with the=20 > UI/UX concern about helping people to understand exactly who they are=20 > leaking their metadata to, presents a really serious obstacle to=20 > deploying something like this in a way that is safe for end users. Absolutely. This might only work if the client, server, and middleboxes inc= entives are well aligned. That may be the case for some basic QOS-type para= meters, which is very much what (b) should be about.=20 > ... > > I don't think something like (c) is a good idea. let's try to keep=20 > the smarts (and the knowledge of both content and metadata) at the=20 > edges of the network, and avoid blessing mechanisms that facilitate centr= alized surveillance. And a variety of security issues. The unauthenticated data channel is subje= ct to spoofing, which enables a variety of packet injection attacks.=20 -- Christian Huitema From nobody Fri Jun 5 16:12:31 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 D14B31ABD35 for ; Fri, 5 Jun 2015 16:12:29 -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_20=-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 V4v-JgERZgxs for ; Fri, 5 Jun 2015 16:12:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBAE1AC398 for ; Fri, 5 Jun 2015 16:11:46 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C1D66F984; Fri, 5 Jun 2015 19:11:43 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1AD8A20304; Fri, 5 Jun 2015 19:11:21 -0400 (EDT) From: Daniel Kahn Gillmor To: Szilveszter Nadas , Christian Huitema , "spud\@ietf.org" In-Reply-To: References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 05 Jun 2015 19:11:21 -0400 Message-ID: <87oaktvjhi.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Spud] SPUD Scope? 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, 05 Jun 2015 23:12:30 -0000 On Fri 2015-06-05 06:37:53 -0400, Szilveszter Nadas wrote: > My concern is whether the whole SPUD exercise is worth the effort > without extensibility. Assume that we can agree in a minimal set for > b). What if in a few years' time we realize that we need more? Have > not we already ossified the middlebox layer? I think the "ossification of the network stack" means something different than what you're using it to mean here. On the networks i deal with, the ossification comes from middleboxes being too fancy, and not just passing traffic the way that edge devices expect. As a result, the software running at the edge squeezes itself into a very limited profile of network traffic just to avoid harrassment/breakage by the (often unknown) middleboxes that might sit on-path to any of its peers. > About "metadata that our protocols leak", I completely agree that > protocols should minimize this leaking. I think that explicit > conversation is not leaking though and hopefully also discourages the > middlebox owners to try to look into the protocol data itself. how does the endpoint know that it is talking to an actual middlebox that is relevant to its communication? the endpoint wants to talk to someone *other* than the middlebox (it wants to talk to the remote peer, the middlebox is just a postal carrier), and it puts itself (and maybe its peer) at risk if it entertains any "explicit conversation" from an adversary posing as a middlebox. There will always be middlebox vendors who think their business is the deepest of packet inspection, whether they claim to offer Data Loss Prevention or Malware Detection or some other unattainable goal. I don't see how any SPUD-like mechanism would deter those vendors from cracking open any layer they can try to crack open. And it sounds like it would give them some points of leverage to start with, as well. > Any device/firmware/Operating System/app still have and will have ways > to leak whatever it wants, just by not allowing extensibility in SPUD > we cannot stop it. At the same time extensible SPUD can be an engine > for "good" cooperation. Let's hear some examples of that "good" cooperation, and make sure they include protections against abuse. So far, the only example i've heard is the ability for peers to mark each packet as delay-tolerant ("please queue") or disposable ("please discard"), so that the middleboxes can make a marginally better guess what to with it do under load. The argument for start/stop signalling for UDP still seems weak to me. > About "keeping the smarts at the edge" the IAB program at least > includes a goal to "(2) Improving path transparency in the presence of > firewalls and middleboxes: guidelines for the detection of and > cooperation with these devices to evolve away from present limitations > on which protocols can be used across network boundaries, in order to > facilitate innovation in transport protocol development. ". You know why we can't innovate in transport protocol development, right? Because too many middleboxes like to block traffic that they find surprising. If they were to stop blocking much of that traffic, we could run things like SCTP or TCPCrypt reliably on the open Internet instead of everyone pretending to be TLS-on-port-443, without the need of anything like SPUD. > About the UI/UX concern. This is definitely an issue and not an easy > one to solve. Trust chains, delegation of trust, market apps > controlling app rights are pieces of the puzzle to solve this. I think > it is possible to find a solution for this with a good balance of ease > of use and control. I've seen no evidence of this (i also don't know what "market apps controlling app rights" means). I'd love to see some pointers to examples of UI/UX mockups that we can reason about (though i don't know if SPUD is the right place to do this). Regards, --dkg From nobody Sat Jun 6 10:44: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 0EE551A9045 for ; Sat, 6 Jun 2015 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.488 X-Spam-Level: **** X-Spam-Status: No, score=4.488 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, DKIM_ADSP_ALL=0.8, SPF_HELO_PASS=-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 PiEKKAsld-Xn for ; Sat, 6 Jun 2015 10:44:38 -0700 (PDT) Received: from mail3.netlab.uky.edu (wonder.netlab.uky.edu [128.163.140.37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55701A9042 for ; Sat, 6 Jun 2015 10:44:38 -0700 (PDT) Received: from culp.local (cpe-96-29-182-38.kya.res.rr.com [96.29.182.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail3.netlab.uky.edu (Postfix) with ESMTPSA id 2B6A6C05D; Sat, 6 Jun 2015 13:44:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ken Calvert In-Reply-To: <87oaktvjhi.fsf@alice.fifthhorseman.net> Date: Sat, 6 Jun 2015 13:44:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> <87oaktvjhi.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD Scope? 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, 06 Jun 2015 17:44:40 -0000 > You know why we can't innovate in transport protocol development, = right? > Because too many middleboxes like to block traffic that they find > surprising. If they were to stop blocking much of that traffic, we > could run things like SCTP or TCPCrypt reliably on the open Internet > instead of everyone pretending to be TLS-on-port-443, without the need > of anything like SPUD. Some middleboxes are paranoid for good (or at least understandable) = reason: they are there to implement trust domain boundaries. Because = those boundaries don't exist in the original architecture, firewalls = work by overloading mechanisms that are poorly suited for the job. A well-designed mechanism that enables a packet to certify = policy-compliance in-band, without DPI, would at least help with = firewalls. It seems to be a necessary condition for reducing the need = to force everything through the TLS-over-443 tube, while still allowing = end-to-end encryption. Yes, the path is fraught with challenges; I don't disagree with most of = your points. On the other hand, call me an optimist, but I believe such = a mechanism could not only help break the "ossification" logjam, but = perhaps eventually shift the balance of power back toward the end users = by giving them more choices w.r.t. network services. Ken Calvert From nobody Sun Jun 7 14:27: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 4C9661ACE71 for ; Sun, 7 Jun 2015 14:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 ZOw6tzwa-b9b for ; Sun, 7 Jun 2015 14:27:47 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8A94A1ACE6F for ; Sun, 7 Jun 2015 14:27:47 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 6984FF985; Sun, 7 Jun 2015 17:27:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CB26121C4C; Sun, 7 Jun 2015 14:30:59 -0400 (EDT) From: Daniel Kahn Gillmor To: Ken Calvert In-Reply-To: <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> <87oaktvjhi.fsf@alice.fifthhorseman.net> <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 07 Jun 2015 14:30:59 -0400 Message-ID: <87vbeztlp8.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD Scope? 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: Sun, 07 Jun 2015 21:27:49 -0000 On Sat 2015-06-06 13:44:33 -0400, Ken Calvert wrote: > Some middleboxes are paranoid for good (or at least understandable) > reason: they are there to implement trust domain boundaries. Because > those boundaries don't exist in the original architecture, firewalls > work by overloading mechanisms that are poorly suited for the job. Maybe. This sounds a lot like someone is still thinking in terms of "perimeter defense", but on most modern, public networks, perimeters are *extremely* porous. And of course, once a threat is inside the perimeter, such a defense is useless. > A well-designed mechanism that enables a packet to certify > policy-compliance in-band, without DPI, would at least help with > firewalls. Maybe we just need to start using "the evil bit" as specified: https://tools.ietf.org/html/rfc3514 ;) Apologies for the snark, but that RFC illuminates the difficulties with providing such an indication in a way that satisfies the security goals you're targeting. Would this be done to implement "trust domain boundaries" securely? > Yes, the path is fraught with challenges; I don't disagree with most > of your points. On the other hand, call me an optimist, but I believe > such a mechanism could not only help break the "ossification" logjam, > but perhaps eventually shift the balance of power back toward the end > users by giving them more choices w.r.t. network services. how would this mechanism give the users more choice w.r.t. network services? It looks lke a way to facilitate additional metadata leakage *to* network providers. are you suggesting that some network providers would require more metadata than others, and users collectively ("the marketplace") could collectively select network providers on the basis of their metadata collection policies? If this is the suggestion, i think it vastly overestimates the average user's (a) knowledge of the underlying mechanism, (b) ability to assess their own risk from particular metadata leakage to a given provider, and (c) time available to deal with the choicepoints presented (by each network connection?) by this scenario. --dkg From nobody Mon Jun 8 00:57: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 8880A1B2D49 for ; Mon, 8 Jun 2015 00:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 M8JevL2el9qi for ; Mon, 8 Jun 2015 00:57:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917581B2D4B for ; Mon, 8 Jun 2015 00:57:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 73946D9319; Mon, 8 Jun 2015 09:57:29 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id x1caYMoPI2aq; Mon, 8 Jun 2015 09:57:29 +0200 (MEST) Received: from [192.168.178.33] (x5f71602c.dyn.telefonica.de [95.113.96.44]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0790ED9303; Mon, 8 Jun 2015 09:57:28 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <87vbeztlp8.fsf@alice.fifthhorseman.net> Date: Mon, 8 Jun 2015 09:57:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47D686FE-C037-42A5-A1F2-7A07318451D0@tik.ee.ethz.ch> References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> <87oaktvjhi.fsf@alice.fifthhorseman.net> <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> <87vbeztlp8.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Ken Calvert , "spud@ietf.org" Subject: Re: [Spud] SPUD Scope? 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: Mon, 08 Jun 2015 07:57:33 -0000 Hi dkg, only one second/last point=E2=80=A6 > Am 07.06.2015 um 20:30 schrieb Daniel Kahn Gillmor = : >=20 > On Sat 2015-06-06 13:44:33 -0400, Ken Calvert wrote: >> Yes, the path is fraught with challenges; I don't disagree with most >> of your points. On the other hand, call me an optimist, but I = believe >> such a mechanism could not only help break the "ossification" logjam, >> but perhaps eventually shift the balance of power back toward the end >> users by giving them more choices w.r.t. network services. >=20 > how would this mechanism give the users more choice w.r.t. network > services? It looks lke a way to facilitate additional metadata = leakage > *to* network providers. are you suggesting that some network = providers > would require more metadata than others, and users collectively ("the > marketplace") could collectively select network providers on the basis > of their metadata collection policies? >=20 > If this is the suggestion, i think it vastly overestimates the average > user's (a) knowledge of the underlying mechanism, (b) ability to = assess > their own risk from particular metadata leakage to a given provider, = and > (c) time available to deal with the choicepoints presented (by each > network connection?) by this scenario. >=20 It=E2=80=99s not the different network providers that need different = information but you may want to provide different information about = different =E2=80=9Akind=E2=80=98 of services so that the provider might = be able to treat your traffic more appropriately (which effectively can = provide you a better service as well as save network resources). = However, a user might choose to not reveal this information and only get = the default treatment which might or might not be good enough (whatever = =E2=80=9Agood=E2=80=98 means here). And here there might actually be = differences between the providers (and the contract that the user made = with its provider). Mirja=20= From nobody Mon Jun 8 04:27:02 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 F07871A1B9E for ; Mon, 8 Jun 2015 04:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, 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 rzXaXnAtciYK for ; Mon, 8 Jun 2015 04:27:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447E91A036D for ; Mon, 8 Jun 2015 04:26:59 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 18511A691F518; Mon, 8 Jun 2015 11:26:56 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t58BQm3U001564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jun 2015 13:26:56 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.234]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 8 Jun 2015 13:26:51 +0200 From: "FOSSATI, Thomas (Thomas)" To: Ken Calvert , Daniel Kahn Gillmor Thread-Topic: [Spud] SPUD Scope? Thread-Index: AdCe42kWUfK3mg2YQc2lRPihacOmIwAB/SYAAABSZ4AAIPnEsAAY51qAACbgyYAAWXdigA== Date: Mon, 8 Jun 2015 11:26:50 +0000 Message-ID: References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> <87oaktvjhi.fsf@alice.fifthhorseman.net> <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> In-Reply-To: <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <98714A3F86F9D34C975CEAC86CFB758A@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD Scope? 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: Mon, 08 Jun 2015 11:27:02 -0000 On 06/06/2015 18:44, "Ken Calvert" wrote: >>You know why we can't innovate in transport protocol development, right? >> Because too many middleboxes like to block traffic that they find >> surprising. If they were to stop blocking much of that traffic, we >> could run things like SCTP or TCPCrypt reliably on the open Internet >> instead of everyone pretending to be TLS-on-port-443, without the need >> of anything like SPUD. > >Some middleboxes are paranoid for good (or at least understandable) >reason: they are there to implement trust domain boundaries. Because >those boundaries don't exist in the original architecture, firewalls work >by overloading mechanisms that are poorly suited for the job. > >A well-designed mechanism that enables a packet to certify >policy-compliance in-band, without DPI, would at least help with >firewalls. It seems to be a necessary condition for reducing the need to >force everything through the TLS-over-443 tube, while still allowing >end-to-end encryption. > >Yes, the path is fraught with challenges; I don't disagree with most of >your points. On the other hand, call me an optimist, but I believe such >a mechanism could not only help break the "ossification" logjam, but >perhaps eventually shift the balance of power back toward the end users >by giving them more choices w.r.t. network services. I totally agree with you, as long as the underlying principles are: - explicit vs implicit service; - ability of endpoints to choose based on clear information about the service value vs leaked meta-data; - preservation of e2e security properties. I think the biggest (though not insurmountable) challenges are: - UX (as already noted by Daniel); - scale mechanism to n middle boxes. We probably need a good deal of research to solve scale and UX, and I hope stackevo has enough breath to account for this. Cheers, t From nobody Mon Jun 8 07:20: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 30A0F1A88D6 for ; Mon, 8 Jun 2015 07:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 TLWjfBPYw0mG for ; Mon, 8 Jun 2015 07:20:10 -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 4EE9D1A88C6 for ; Mon, 8 Jun 2015 07:20:10 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-02-5575a4985617 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 24.89.28096.894A5755; Mon, 8 Jun 2015 16:20:08 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.142]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Mon, 8 Jun 2015 16:20:08 +0200 From: Szilveszter Nadas To: "FOSSATI, Thomas (Thomas)" , "Ken Calvert" , Daniel Kahn Gillmor Thread-Topic: [Spud] SPUD Scope? Thread-Index: AdCe42kWUfK3mg2YQc2lRPihacOmIwAB/SYAAABSZ4AAIPnEsAAY51qAACbgyYAAWXdigAAHpPzA Date: Mon, 8 Jun 2015 14:20:07 +0000 Message-ID: References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> <87oaktvjhi.fsf@alice.fifthhorseman.net> <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3VnfGktJQg8135C3WnOhjsWjt/sxk sejCU0aLVd8usTiweLQ+28vqcba7ndVjyZKfTB63Hx5nCWCJ4rJJSc3JLEst0rdL4MrY3DiR qeAjb8XP55/ZGhhncHcxcnJICJhIHJi3lwXCFpO4cG89WxcjF4eQwFFGib+HZrODJIQEFjNK nOznBbHZBCwkGlZuZgOxRQRmM0q0PlAAsZkFlCVmLNzFCGILC8hL/N+8kR2iRkHiz5Q+qPoo icNXljKB2CwCKhJ71z9hBrF5BXwltl75yQ6xeDWzxMmvN8EaOAXsJVbs3wvWwAh03fdTa5gg lolL3HoynwniagGJJXvOM0PYohIvH/9jhbCVJH5suMQCUa8jsWD3JzYIW1ti2cLXUIsFJU7O fMIygVFsFpKxs5C0zELSMgtJywJGllWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgZF2cMtv qx2MB587HmIU4GBU4uF9sK8kVIg1say4MvcQozQHi5I474zNeaFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGPV/JNo2dRecP5qk1eF88MVc1b1bJsXKPQz+2ZaZmFMRNjNfbW3+J85Vn6z0 G6ZdPfCiw+yiCXdx0Nu1TI7cSi4NwV///jCwn3xDI2DnsTXOIWLHt5ywcXt090i+3LG6/Rmu 8ifLg/4lvbxz469cprnR8o13E6JuWM1iZNsfVhXy8bJRkMw3VyWW4oxEQy3mouJEAIu/teKV AgAA Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] SPUD Scope? 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: Mon, 08 Jun 2015 14:20:12 -0000 Hi, >>Yes, the path is fraught with challenges; I don't disagree with most of=20 >>your points. On the other hand, call me an optimist, but I believe=20 >>such a mechanism could not only help break the "ossification" logjam,=20 >>but perhaps eventually shift the balance of power back toward the end=20 >>users by giving them more choices w.r.t. network services. I share the same belief. I think that middleboxes must demonstrate their value for one of the ends i= n order to receive metadata. This is what I mean on them being explicit. Ho= wever if they do demonstrate then I believe in giving them the information = they want.=20 I personally prefer that even without metadata a reasonable default service= is available. How to achieve this is a good question. I guess regulators h= ave bigger rule here than engineers. Though I believe that engineers are re= sponsible to educate regulators to find the right path. Without the right r= egulation blocking when not getting metadata can always happen even if we m= ake it harder with protocol design. >I totally agree with you, as long as the underlying principles are: >- explicit vs implicit service; >- ability of endpoints to choose based on clear information about the serv= ice value vs leaked meta-data; >- preservation of e2e security properties. > >I think the biggest (though not insurmountable) challenges are: >- UX (as already noted by Daniel); >- scale mechanism to n middle boxes. > >We probably need a good deal of research to solve scale and UX, and I hope= stackevo has enough breath to account for this. I agree. I am thinking about writing a draft along these lines and also inc= lude some example use cases with "good" cooperation examples. Cheers, Sz. From nobody Mon Jun 8 07:27: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 A99461A88E9 for ; Mon, 8 Jun 2015 07:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] 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 nTIP0kImlQmE for ; Mon, 8 Jun 2015 07:27:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7F28B1A8912 for ; Mon, 8 Jun 2015 07:27:20 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 23CB1F984; Mon, 8 Jun 2015 10:27:17 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BB48E2044C; Mon, 8 Jun 2015 10:26:54 -0400 (EDT) From: Daniel Kahn Gillmor To: Mirja =?utf-8?Q?K=C3=BChlewind?= In-Reply-To: <47D686FE-C037-42A5-A1F2-7A07318451D0@tik.ee.ethz.ch> References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> <87oaktvjhi.fsf@alice.fifthhorseman.net> <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> <87vbeztlp8.fsf@alice.fifthhorseman.net> <47D686FE-C037-42A5-A1F2-7A07318451D0@tik.ee.ethz.ch> User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 08 Jun 2015 10:26:54 -0400 Message-ID: <87ioaytgwh.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Ken Calvert , "spud@ietf.org" Subject: Re: [Spud] SPUD Scope? 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: Mon, 08 Jun 2015 14:27:22 -0000 Hi Mirja-- On Mon 2015-06-08 03:57:28 -0400, Mirja Kühlewind wrote: > It’s not the different network providers that need different > information but you may want to provide different information about > different ‚kind‘ of services so that the provider might be able to > treat your traffic more appropriately (which effectively can provide > you a better service as well as save network resources). However, a > user might choose to not reveal this information and only get the > default treatment which might or might not be good enough (whatever > ‚good‘ means here). And here there might actually be differences > between the providers (and the contract that the user made with its > provider). We've been talking about generic middleboxes so far, and this is the Internet; almost by definition there will be middleboxes that have no contracts with the user. It's quite likely for any given path between two peers that there will be *no* middleboxes on the path that actually have a contractual relationship with either peer. --dkg From nobody Mon Jun 8 09:10: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 C4E691B2FD3 for ; Mon, 8 Jun 2015 09:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 RwwCpEvV3J7i for ; Mon, 8 Jun 2015 09:10:43 -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 9C0731B2FE5 for ; Mon, 8 Jun 2015 09:08:58 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so65298783igb.1 for ; Mon, 08 Jun 2015 09:08:58 -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=axMxZSgayuAMs6BKs7jtA198lapNZJwu9EktbKlDxg4=; b=Lh8x+jJ3fUpa6hK8rynPBzJmIPZsVBcFfI5IEd3hFJPnzybatsyhI9t4inAYM7fAo2 upzQvnRnfIg/Hhiq5QRbOL1sIE/ONar4xZhw2DXbdcWkdDXLcWZFUM3jtlaCysmp/N4I qcbyBIWYMmIQhRbkuqu7qTxmBdF1UrL9SXEXiZ6suEec5GhYjuSmwWCZRYqQdvYNDJNe VUmdTA4oYlRXyfUL3PNIRYFkhzjBB6KLM1d/CjR2eqPaRBGO+XsisYsPnorwiEFlB3fV O5L/5RdmGZgqWj1O+15U+sq6U8jzANvXwhzif/XxbfrEfwNdegSqgPNyBfqRMfxW3jRw N+Zg== X-Gm-Message-State: ALoCoQm7YBcyR/AfHynJtNdfKEn/jUp1jvW2QCinVGM3Cn7/NatitUuxF+Sme0daxll8Jf+/3B9I MIME-Version: 1.0 X-Received: by 10.50.142.67 with SMTP id ru3mr14435408igb.16.1433779737898; Mon, 08 Jun 2015 09:08:57 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Mon, 8 Jun 2015 09:08:57 -0700 (PDT) In-Reply-To: <87ioaytgwh.fsf@alice.fifthhorseman.net> References: <87h9qn1dkr.fsf@alice.fifthhorseman.net> <87oaktvjhi.fsf@alice.fifthhorseman.net> <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> <87vbeztlp8.fsf@alice.fifthhorseman.net> <47D686FE-C037-42A5-A1F2-7A07318451D0@tik.ee.ethz.ch> <87ioaytgwh.fsf@alice.fifthhorseman.net> Date: Mon, 8 Jun 2015 09:08:57 -0700 Message-ID: From: Tom Herbert To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ken Calvert , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "spud@ietf.org" Subject: Re: [Spud] SPUD Scope? 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: Mon, 08 Jun 2015 16:10:49 -0000 On Mon, Jun 8, 2015 at 7:26 AM, Daniel Kahn Gillmor wrote: > Hi Mirja-- > > On Mon 2015-06-08 03:57:28 -0400, Mirja K=C3=BChlewind wrote: >> It=E2=80=99s not the different network providers that need different >> information but you may want to provide different information about >> different =E2=80=9Akind=E2=80=98 of services so that the provider might = be able to >> treat your traffic more appropriately (which effectively can provide >> you a better service as well as save network resources). However, a >> user might choose to not reveal this information and only get the >> default treatment which might or might not be good enough (whatever >> =E2=80=9Agood=E2=80=98 means here). And here there might actually be dif= ferences >> between the providers (and the contract that the user made with its >> provider). > > We've been talking about generic middleboxes so far, and this is the > Internet; almost by definition there will be middleboxes that have no > contracts with the user. It's quite likely for any given path between > two peers that there will be *no* middleboxes on the path that actually > have a contractual relationship with either peer. > Unfortunately this is isn't completely true between end users and middleboxes. There are growing use cases where middleboxes are used to enforce a service contract with users as to what applications are allowed to pass through the network. For instance, some network providers will not allow video as a basic service (IMO this is the antithesis of net neutrality, but nevertheless we need to consider this reality). One upshot of this is that middleboxes need to perform DPI which becomes a problem if middleboxes can't identify the application, so a consequence may be that e2e security (e.g. TLS) is completely disallowed. Tom > --dkg > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon Jun 8 09:21: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 60E8B1B303B for ; Mon, 8 Jun 2015 09:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 KI4onoiG4Vnb for ; Mon, 8 Jun 2015 09:21:12 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 CEF241B3039 for ; Mon, 8 Jun 2015 09:21:11 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so107631243wgb.3 for ; Mon, 08 Jun 2015 09:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NyI0ZvP6+QL9f8Ob/eEdTWWYx0hwTTm9izJEfv0uqwU=; b=G4zLLsdEtg5B0CCFYzUOg0UFlv7lkvsg3SN9zsDZS1w949VxjU5HZxoX+CBkl/1lzw wqbQoQgf1hYsIs4vInPmqTvgrlQCuJ70ivJovp+FL9KB7wffhYsNwJLH+UveLTjggswN mEao1/fhxXsu5lJBCzVMPzl7YJ6b8O4UkjNyGHkye2jHnyH3tDg8mxP26WpPCDsSnAOy +wkMBYXKVMtM/oO8ITs1bXFBJRQ25CeUeu6a6k8qZm7Av/VhnFpUQ7+RZnXH4mi60k+d wq0TnM1+D+CkbmXiubgVAE2lDFSixl4oCvPD0jdaFrizGSHtEFY4KF4JmsAg972L/Zb/ 7Jwg== MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr33878686wjc.26.1433780470561; Mon, 08 Jun 2015 09:21:10 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Mon, 8 Jun 2015 09:21:10 -0700 (PDT) Date: Mon, 8 Jun 2015 09:21:10 -0700 Message-ID: From: Ted Hardie To: "spud@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb03a92a241b30518040771 Archived-At: Subject: [Spud] Balancing optimiizations (was SPUD Scope) 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: Mon, 08 Jun 2015 16:21:18 -0000 --047d7bb03a92a241b30518040771 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, So, reading through =E2=80=8Bthe comment thread on scope, I felt again that we're missing the c= haracter of the work as experimental and, more importantly, as supporting experimentation. The question we're asking, at its core, is how do we increase the ability of protocols to explore different congestion control, pacing, and reliability parameters (a.k.a. how do we evolve the protocols using the network)? It has become apparent that some of that experimentation is going on in user space, using UDP as a substrate. SPUD is trying to extend that substrate to provide a common mechanism for indicating specific packets are grouped together, so that experiments can determine whether network treatment can vary when they are so grouped. The extensions beyond that are to determine whether network treatment can be influenced by semantics attached to the grouping. The core commands are similar to those already shared by TCP: open, close, ack, normal data. =E2=80=8BAll the declaration bits after that point are potential optimizati= ons that can be dropped=E2=80=8B at any time by any party, but the experiments the availability of those bits allow you to run are important. A core question behind those experiements is "Can you tell the path something the elicits specific network treatment without disclosing more than the desired treatment?". The corresponding question is "Can how the application puts traffic onto a path vary in response to path indications without simply trusting those declarations?" The experiments may end up answering those questions with "Yes" or "No", but we'd like to run the experiments to see. No one thinks SPUD is done or ready for standardization; it's not. =E2=80=8BIt's context for a set of experiments, not a solution. The result = may tell us that the grouping mechanism does no good and the whole effort should drop. It may tell us that the grouping is useful and some, but not all, of the core commands work. It may tell us that only declarative bits like "discard-preferred" are safe.=E2=80=8B But if we can't experiment at all with what common substrates would look like, we know our evolution has limits. Those limits don't necessarily produce better privacy results; it just pushes the problem into each protocol built on UDP and ossifies whatever choices made it through middleboxes already. =E2=80=8BI think the community should see if that's better before deciding = it is so. =E2=80=8B No hats, Ted --047d7bb03a92a241b30518040771 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

So, reading through =E2=80=8Bthe comment thread on scope, I felt again t= hat we're missing the character of the work as experimental and, more i= mportantly, as supporting experimentation.

The question we're aski= ng, at its core, is how do we increase the ability of protocols to explore = different congestion control, pacing, and reliability parameters (a.k.a. ho= w do we evolve the protocols using the network)?=C2=A0

It has becom= e apparent that some of that experimentation is going on in user space, usi= ng UDP as a substrate.=C2=A0 SPUD is trying to extend that substrate to pro= vide a common mechanism for indicating specific packets are grouped togethe= r, so that experiments can determine whether network treatment can vary whe= n they are so grouped.=C2=A0 The extensions beyond that are to determine wh= ether network treatment can be influenced by semantics attached to the grou= ping.=C2=A0 The core commands are similar to those already shared by TCP:= =C2=A0 open, close, ack, normal data.=C2=A0

=E2=80=8BAll the declaration bits a= fter that point are potential optimizations that can be dropped=E2=80=8B at= any time by any party, but the experiments the availability of those bits = allow you to run are important.=C2=A0 A core question behind those experiem= ents is=C2=A0 "Can you tell the path something the elicits specific ne= twork treatment without disclosing more than the desired treatment?".= =C2=A0 The corresponding question is "Can how the application puts tra= ffic onto a path vary in response to path indications without simply trusti= ng those declarations?"=C2=A0 The experiments may end up answering tho= se questions with "Yes" or "No", but we'd like to r= un the experiments to see.

No one thinks SPUD is done or ready for standardi= zation; it's not.=C2=A0
=E2=80=8BIt's cont= ext for a set of experiments, not a solution. The result may tell us that t= he grouping mechanism does no good and the whole effort should drop.=C2=A0 = It may tell us that the grouping is useful and some, but not all, of the co= re commands work.=C2=A0 It may tell us that only declarative bits like &quo= t;discard-preferred" are safe.=E2=80=8B


But if we can'= ;t experiment at all with what common substrates would look like, we know o= ur evolution has limits.=C2=A0 Those limits don't necessarily produce b= etter privacy results; it just pushes the problem into each protocol built = on UDP and ossifies whatever choices made it through middleboxes already.= =C2=A0
=E2=80=8BI think the community should see i= f that's better before deciding it is so.
=E2=80=8B=C2=A0


No hats,

Ted
=

--047d7bb03a92a241b30518040771-- From nobody Fri Jun 12 02:49:09 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 5AD8F1A8A87 for ; Fri, 12 Jun 2015 02:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 EycM41d4GTkc for ; Fri, 12 Jun 2015 02:49:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C271A8ADE for ; Fri, 12 Jun 2015 02:49:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXH40179; Fri, 12 Jun 2015 09:49:03 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 12 Jun 2015 10:49:02 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.68]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 12 Jun 2015 17:48:56 +0800 From: Youjianjie To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Martin Stiemerling Thread-Topic: [Spud] Numbers... Thread-Index: AQHQZveT5lJPfkOmdkOe80G8x/ARcZ0sob4AgHx3muA= Date: Fri, 12 Jun 2015 09:48:55 +0000 Message-ID: References: <5512AA84.80107@gmail.com> <7276B84D-7540-4DFC-82EC-1246EF96EFF0@tik.ee.ethz.ch> In-Reply-To: <7276B84D-7540-4DFC-82EC-1246EF96EFF0@tik.ee.ethz.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "spud@ietf.org" Subject: [Spud] =?utf-8?b?562U5aSNOiAgTnVtYmVycy4uLg==?= 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, 12 Jun 2015 09:49:07 -0000 SGksDQoNCkknbSBhbHNvIGNvbmZ1c2VkIGFib3V0IHRoZSBmb2xsb3dpbmcgZGVzY3JpcHRpb246 DQoiVG9kYXkgVURQIGlzIG9mdGVuIGJsb2NrZWQgKOKAnDk5JSBvZiBVRFAgaXMgZ2FyYmFnZeKA nSkgYnV0IHZvbHVtZSBvZiAoZ29vZCkgVURQIHRyYWZmaWMgZ3Jvd3MsIGUuZy4gUlRDV0VCIHVz ZXMgVURQIGZvciBkYXRhIGFuZCBtZWRpYSINCg0KV2hhdCBraW5kIG9mIFVEUCBpcyBjYWxsZWQg Z2FyYmFnZT8gV2h5IFVEUCBpcyBvZnRlbiBibG9ja2VkPw0KQ291bGQgc29tZWJvZHkgcGxlYXNl IGV4cGxhaW4/DQoNClRoYW5rcywNCkppYW5qaWUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0t DQo+IOWPkeS7tuS6ujogU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGo IE1pcmphIEvDvGhsZXdpbmQNCj4g5Y+R6YCB5pe26Ze0OiAyMDE15bm0M+aciDI15pelIDIwOjU1 DQo+IOaUtuS7tuS6ujogTWFydGluIFN0aWVtZXJsaW5nDQo+IOaKhOmAgTogc3B1ZEBpZXRmLm9y Zw0KPiDkuLvpopg6IFJlOiBbU3B1ZF0gTnVtYmVycy4uLg0KPiANCj4gSGkgTWFydGluLA0KPiAN Cj4gdGhpcyBzZW50ZW5jZSBpcyBpbiBxdW90ZXMgYmVjYXVzZSB0aGF04oCZcyBzdHVmZiBwZW9w bGUgZGlkIGFjdHVhbGx5IHNheSB0byBtZSBvcg0KPiBvdGhlcnMuIDk5JSBpcyBub3QgdHJ1ZSBi dXQgdGhlcmUgYXJlIGN1cnJlbnRseSBubyBudW1iZXIgcHVibGljbHkgYXZhaWxhYmxlIHRvDQo+ IG91ciBrbm93bGVkZ2UuIFdlIGp1c3Qgc3RhcnRlZCBtZWFzdXJlbWVudHMgb24gdGhpcyBhbmQg d2UgYXJlIGFsc28NCj4gY3VycmVudGx5IHRhbGtpbmcgdG8gcGVvcGxlIHdobyBtaWdodCBoYXZl IHNvbWUgbnVtYmVycyBlLmcuIGZvcg0KPiBjaHJvbWUvUVVJQyAodGhhdOKAmXMgcGFydCBvZiB0 aGUgaG9wcyBhY3Rpdml0eSkuDQo+IA0KPiBNaXJqYQ0KPiANCj4gDQo+ID4gQW0gMjUuMDMuMjAx NSB1bSAwNzozMSBzY2hyaWViIE1hcnRpbiBTdGllbWVybGluZyA8bWxzLmlldGZAZ21haWwuY29t PjoNCj4gPg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IEkgYW0ganVzdCBnb2luZyB0aHJvdWdoIHRo ZSBzbGlkZXMgZm9yIHRvZGF5J3MgQk9GIGFuZCBqdXN0IGdvdCBzdHVjayBvbiBzbGlkZSA1DQo+ IG9mIHdoaWNoIHNheXM6DQo+ID4gIlRvZGF5IFVEUCBpcyBvZnRlbiBibG9ja2VkICjigJw5OSUg b2YgVURQIGlzIGdhcmJhZ2XigJ0pIGJ1dCB2b2x1bWUgb2YNCj4gPiAoZ29vZCkgVURQIHRyYWZm aWMgZ3Jvd3MsIGUuZy4gUlRDV0VCIHVzZXMgVURQIGZvciBkYXRhIGFuZCBtZWRpYSINCj4gPg0K PiA+IElzIHRoZXJlIHJlbGlhYmxlIGRhdGEgdGhhdCB1bmRlcnNjb3JlcyBVRFAgaXMgb2Z0ZW4g YmxvY2tlZD8NCj4gPg0KPiA+IEkgY2FuIHNlZSBjYXNlcywgZS5nLiwgZW50ZXJwcmlzZXMgd2hl cmUgdGhpcyBpcyB0cnVlLCBidXQgaW4gbW9zdCBvdGhlcg0KPiBzZXR0aW5ncyBteSBVRFAgdHJh ZmZpYyBpcyBqdXN0IG1ha2luZyBpdCB0byB0aGUgb3RoZXIgZW5kLCBieSB0b2RheS4gV2FzDQo+ IGRpZmZlcmVudCBhIGNvdXBsZSBvZiB5ZWFycyBhZ28sIHdoZW4gdGhlcmUgd2FzIG5vIHN0YXRl ZnVsIGZpbHRlcmluZyBvZiBVRFANCj4gdHJhZmZpYyBpbXBsZW1lbnRlZC4NCj4gPg0KPiA+IFRo YW5rcywNCj4gPg0KPiA+ICBNYXJ0aW4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gU3B1ZCBtYWlsaW5nIGxpc3QNCj4gPiBTcHVk QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVk DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBTcHVkIG1haWxpbmcgbGlzdA0KPiBTcHVkQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3B1ZA0K From nobody Fri Jun 12 03:03:42 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 E56261A8A6A for ; Fri, 12 Jun 2015 03:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 nGYHNtMhzv4k for ; Fri, 12 Jun 2015 03:03:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350CC1A8A3F for ; Fri, 12 Jun 2015 03:03:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 32434D9309; Fri, 12 Jun 2015 12:03:31 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QPNElXKhz-Ry; Fri, 12 Jun 2015 12:03:31 +0200 (MEST) Received: from [192.168.178.33] (x5f71a12e.dyn.telefonica.de [95.113.161.46]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A9BA6D9307; Fri, 12 Jun 2015 12:03:30 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 12 Jun 2015 12:03:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E267AE0-96D5-44F9-BA3F-AB4987EB0781@tik.ee.ethz.ch> References: <5512AA84.80107@gmail.com> <7276B84D-7540-4DFC-82EC-1246EF96EFF0@tik.ee.ethz.ch> To: Youjianjie X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Martin Stiemerling , "spud@ietf.org" Subject: Re: [Spud] =?utf-8?b?562U5aSNOiAgTnVtYmVycy4uLg==?= 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, 12 Jun 2015 10:03:41 -0000 Hi Jianjie, This sentence is set in quotes as the 99% are not a real number. = However, the point is that we hear people saying things like this, even = though that is not true (anymore). Under the assumption that basically all UDP traffic is garbage anyway = (which is not true), something UDP is simply completely blocked. This is = mainly the case for enterprise networks but I=E2=80=99ve heard similar = things from network providers, even though I cannot imagine that any = network provider would largely block UDP anywhere. Anyway the other problem with UDP is to create state as there is no = common notion of something like start and end of a =E2=80=9Eflow=E2=80=9C = which is a very first precondition to establish firewall rules that = would allow certain UDP traffic to pass. Does this help you? Mirja > Am 12.06.2015 um 11:48 schrieb Youjianjie : >=20 > Hi, >=20 > I'm also confused about the following description: > "Today UDP is often blocked (=E2=80=9C99% of UDP is garbage=E2=80=9D) = but volume of (good) UDP traffic grows, e.g. RTCWEB uses UDP for data = and media" >=20 > What kind of UDP is called garbage? Why UDP is often blocked? > Could somebody please explain? >=20 > Thanks, > Jianjie >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Spud [mailto:spud-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Mirja K=C3=BChlewind >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8825=E6=97=A5= 20:55 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Martin Stiemerling >> =E6=8A=84=E9=80=81: spud@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [Spud] Numbers... >>=20 >> Hi Martin, >>=20 >> this sentence is in quotes because that=E2=80=99s stuff people did = actually say to me or >> others. 99% is not true but there are currently no number publicly = available to >> our knowledge. We just started measurements on this and we are also >> currently talking to people who might have some numbers e.g. for >> chrome/QUIC (that=E2=80=99s part of the hops activity). >>=20 >> Mirja >>=20 >>=20 >>> Am 25.03.2015 um 07:31 schrieb Martin Stiemerling = : >>>=20 >>> Hi all, >>>=20 >>> I am just going through the slides for today's BOF and just got = stuck on slide 5 >> of which says: >>> "Today UDP is often blocked (=E2=80=9C99% of UDP is garbage=E2=80=9D) = but volume of >>> (good) UDP traffic grows, e.g. RTCWEB uses UDP for data and media" >>>=20 >>> Is there reliable data that underscores UDP is often blocked? >>>=20 >>> I can see cases, e.g., enterprises where this is true, but in most = other >> settings my UDP traffic is just making it to the other end, by today. = Was >> different a couple of years ago, when there was no stateful filtering = of UDP >> traffic implemented. >>>=20 >>> Thanks, >>>=20 >>> Martin >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >> _______________________________________________ >> 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 Jun 12 07:38: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 095941ACCED for ; Fri, 12 Jun 2015 07:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.425 X-Spam-Level: X-Spam-Status: No, score=-5.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, 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 C4KPEy8mkQp5 for ; Fri, 12 Jun 2015 07:38:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF441ACCE6 for ; Fri, 12 Jun 2015 07:38:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BgEQDr7XpV/4cNJK1cgxBUX61KkCUJgTgfCoRwgk04FAEBAQEBAQGBCkEDg2AGAQEvAS0OCxsYCR4WBQ0GHxcBEogaAxIN0FANhVYBAQEBBgEBAQEBAQEBFgSLQ4JNhm0FjGaIGYgzgV8BgTKBKoJXi0CHFSaCCxyBch4xgkcBAQE X-IronPort-AV: E=Sophos;i="5.13,602,1427760000"; d="scan'208";a="3009247" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 12 Jun 2015 14:38:42 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5CEcdc4020186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2015 14:38: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 t5CEccPg027696; Fri, 12 Jun 2015 07:38:39 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t5CEccNm027695; Fri, 12 Jun 2015 07:38:38 -0700 Date: Fri, 12 Jun 2015 07:38:38 -0700 From: Youjianjie To: mirja.kuehlewind@tik.ee.ethz.ch, Martin Stiemerling Message-ID: <20150612143838.GJ27147@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] ??????: Numbers... 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, 12 Jun 2015 14:38:43 -0000 I have never heard 99% of UDP is trash to be true. Security folks in Cisco told me "a lot of unix networking apps from the 80th/90th based on UDP where extremely insecure", and i think thats definitely true and has lead the first wave of firewalling off UDP. The second wave was p2p sharing apps which also caused a lot of enterprises to be weary of UDP and firewall it. On Fri, Jun 12, 2015 at 09:48:55AM +0000, Youjianjie wrote: > Hi, > > I'm also confused about the following description: > "Today UDP is often blocked (???99% of UDP is garbage???) but volume of (good) UDP traffic grows, e.g. RTCWEB uses UDP for data and media" > > What kind of UDP is called garbage? Why UDP is often blocked? > Could somebody please explain? > > Thanks, > Jianjie > > > -----????????????----- > > ?????????: Spud [mailto:spud-bounces@ietf.org] ?????? Mirja Kühlewind > > ????????????: 2015???3???25??? 20:55 > > ?????????: Martin Stiemerling > > ??????: spud@ietf.org > > ??????: Re: [Spud] Numbers... > > > > Hi Martin, > > > > this sentence is in quotes because that???s stuff people did actually say to me or > > others. 99% is not true but there are currently no number publicly available to > > our knowledge. We just started measurements on this and we are also > > currently talking to people who might have some numbers e.g. for > > chrome/QUIC (that???s part of the hops activity). > > > > Mirja > > > > > > > Am 25.03.2015 um 07:31 schrieb Martin Stiemerling : > > > > > > Hi all, > > > > > > I am just going through the slides for today's BOF and just got stuck on slide 5 > > of which says: > > > "Today UDP is often blocked (???99% of UDP is garbage???) but volume of > > > (good) UDP traffic grows, e.g. RTCWEB uses UDP for data and media" > > > > > > Is there reliable data that underscores UDP is often blocked? > > > > > > I can see cases, e.g., enterprises where this is true, but in most other > > settings my UDP traffic is just making it to the other end, by today. Was > > different a couple of years ago, when there was no stateful filtering of UDP > > traffic implemented. > > > > > > Thanks, > > > > > > Martin > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Fri Jun 12 10:22: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 3EC7F1ACDA8 for ; Fri, 12 Jun 2015 10:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 9IAJGTQtHYHA for ; Fri, 12 Jun 2015 10:22:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0123.outbound.protection.outlook.com [207.46.100.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632D21A6F30 for ; Fri, 12 Jun 2015 10:22:17 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.184.17; Fri, 12 Jun 2015 17:22:16 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0184.014; Fri, 12 Jun 2015 17:22:16 +0000 From: Christian Huitema To: Youjianjie , "mirja.kuehlewind@tik.ee.ethz.ch" , Martin Stiemerling Thread-Topic: [Spud] ??????: Numbers... Thread-Index: AQHQpR1+Czu+JOuglEWWdj5aI8lU/52pHV7A Date: Fri, 12 Jun 2015 17:22:15 +0000 Message-ID: References: <20150612143838.GJ27147@cisco.com> In-Reply-To: <20150612143838.GJ27147@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 3:5ZqT7bXqS4OCdYqKkFEjtBPNUg5COEfYdoX4vsYz/rfBtX8RvwRrxt4LR5zf35P9Dzq6VGeve6QugnGGJJBrtuTTBZCme0oiBZJQN7yZfQdcdhQyWOOoP6tlYq2OCheE+qoPAyREY38wgF/yfZUYAw==; 10:qtGxpAXWbmCD2rPKjC0zTyv84frLPXZ7Jqwygw+eR5TSUJemkWNhvY1XgG+y5ByTpLEI3Gfkee39hTIW19HCTdu6ZWwyTvuxg3lsAZSBpRA=; 6:M/Y1Pjob8J6RfElL5dw+gc6ViV8FYycPzN1GoDk1wMRgqjFOaG0Zk2g4a1bNdcQk x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(2656002)(87936001)(86362001)(189998001)(106116001)(46102003)(5001960100002)(33656002)(50986999)(54356999)(5002640100001)(76176999)(92566002)(74316001)(5001770100001)(40100003)(2501003)(2950100001)(102836002)(77156002)(99286002)(2900100001)(77096005)(62966003)(5003600100002)(76576001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2015 17:22:15.6365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] ??????: Numbers... 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, 12 Jun 2015 17:22:23 -0000 > I have never heard 99% of UDP is trash to be true. Security folks in Cisc= o told me > "a lot of unix networking apps from the 80th/90th based on UDP where > extremely insecure", and i think thats definitely true and has lead the f= irst wave > of firewalling off UDP. The second wave was p2p sharing apps which also > caused a lot of enterprises to be weary of UDP and firewall it. Two big applications that are running over UDP: voice and video with Skype,= video-games with Xbox Live. Of course, there are places where UDP is block= ed, in which case UDP applications will try tunneling over HTTPS. But in th= e vast majority of consumer networks, these applications use UDP just fine. -- Christian Huitema From nobody Fri Jun 12 16:37:37 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 231F71A8859 for ; Fri, 12 Jun 2015 16:37:36 -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 q4A8uwtq5nHU for ; Fri, 12 Jun 2015 16:37:34 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.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 9604E1A87A8 for ; Fri, 12 Jun 2015 16:37:34 -0700 (PDT) Received: by iesa3 with SMTP id a3so32944747ies.2 for ; Fri, 12 Jun 2015 16:37:34 -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=HMqCF476sE8j/VK1bYdn7ex3jcKryyOogsa5/a87W0w=; b=AW1ixEsqEdjhsiKZSEUIP+b2JsCC8PKG0017UBA29U0PH2EWxHw3Gqjdh4G6xQJATS rG6hHEyDgKC+2ymDkOn4xNL0Pqrk6iQ5yq2D9sI11jp3hmUzrIVd3xkVVWaseMIy1/Ph +XyJyL3y8MRpv/1o6cQP02cWHiwY5bZ/sFnjsoRNmR4ktjbXPHFFHu6EMrhPgTIezVXT /+SZdKTme506kd0Y2gPIwfnUM8jEx68mEderzkx4fbD4X1qfuVuBu+OL2oiak5/in/xH 7XQWowR2m0Z8VBNxibSthHg21vsu+6GNlVBIZXsz5cwjApKx2qU8UIlcgFvU/iuD7/hH 5s0A== X-Gm-Message-State: ALoCoQn4K+PAEuekMOMO43B8B8QMuI8rD2JD+NnlRnsmVGQfybS+P8jqWk0uJQRlxegf3f10+2ni MIME-Version: 1.0 X-Received: by 10.50.90.179 with SMTP id bx19mr7512075igb.43.1434152253970; Fri, 12 Jun 2015 16:37:33 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Fri, 12 Jun 2015 16:37:33 -0700 (PDT) In-Reply-To: References: <20150612143838.GJ27147@cisco.com> Date: Fri, 12 Jun 2015 16:37:33 -0700 Message-ID: From: Tom Herbert To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "mirja.kuehlewind@tik.ee.ethz.ch" , "spud@ietf.org" , Youjianjie , Martin Stiemerling Subject: Re: [Spud] ??????: Numbers... 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, 12 Jun 2015 23:37:36 -0000 On Fri, Jun 12, 2015 at 10:22 AM, Christian Huitema wrote: >> I have never heard 99% of UDP is trash to be true. Security folks in Cis= co told me >> "a lot of unix networking apps from the 80th/90th based on UDP where >> extremely insecure", and i think thats definitely true and has lead the = first wave >> of firewalling off UDP. The second wave was p2p sharing apps which also >> caused a lot of enterprises to be weary of UDP and firewall it. > > Two big applications that are running over UDP: voice and video with Skyp= e, video-games with Xbox Live. Of course, there are places where UDP is blo= cked, in which case UDP applications will try tunneling over HTTPS. But in = the vast majority of consumer networks, these applications use UDP just fin= e. > Christian, You present a very interesting datapoint, but I'm not sure how to interpret it. Is UDP getting far reach now because most users are not behind firewalls, firewalls are allowing all UDP to pass, or holes have been commonly punched in firewalls for specific applications? Would this imply there is less need to implement a UDP based protocol to work with stateful firewalls? Thanks, Tom > -- Christian Huitema > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Jun 12 16:43: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 B8CD71A87BC for ; Fri, 12 Jun 2015 16:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 lcVDfFXgszsp for ; Fri, 12 Jun 2015 16:43:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050D81A1EF2 for ; Fri, 12 Jun 2015 16:43:38 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.184.17; Fri, 12 Jun 2015 23:43:01 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0184.014; Fri, 12 Jun 2015 23:43:00 +0000 From: Christian Huitema To: Tom Herbert Thread-Topic: [Spud] ??????: Numbers... Thread-Index: AQHQpWjC4RjAMdyoxEigQHKEkqNz6J2ph0nA Date: Fri, 12 Jun 2015 23:43:00 +0000 Message-ID: References: <20150612143838.GJ27147@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: herbertland.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 10:U2BE2Yy0YIEuSl6kyJBVbs0YrVhVQzz09dAgQMGpg+OKtyF/L2WFLjcinNCVwLgMHMvTRrib39CLZ1v25AfdHLOeuc89Z6sUoS/DwCGZpLE=; 6:7eWUUrxK7idSQjS7YyF2KLy5SHlTo9jLAOFC7/ObMsorucgRu79LcxTplKQMIcza x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2656002)(86362001)(189998001)(106116001)(46102003)(87936001)(5001960100002)(33656002)(50986999)(54356999)(5002640100001)(76176999)(92566002)(74316001)(62966003)(40100003)(2950100001)(102836002)(110136002)(99286002)(77156002)(2900100001)(77096005)(76576001)(122556002)(5003600100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2015 23:43:00.7283 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: "mirja.kuehlewind@tik.ee.ethz.ch" , "spud@ietf.org" , Youjianjie , Martin Stiemerling Subject: Re: [Spud] ??????: Numbers... 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, 12 Jun 2015 23:43:40 -0000 PiBXb3VsZCB0aGlzIGltcGx5IHRoZXJlIGlzIGxlc3MgbmVlZCB0byBpbXBsZW1lbnQgYSBVRFAg YmFzZWQgcHJvdG9jb2wNCj4gdG8gd29yayB3aXRoIHN0YXRlZnVsIGZpcmV3YWxscz8NCg0KTW9z dCBlbmQgcG9pbnRzIGFyZSBiZWhpbmQgc29tZSBraW5kIG9mIGZpcmV3YWxsIG9yIE5BVC4gVURQ IHdvcmtzIHRocm91Z2ggdGhhdCwgbGFyZ2VseSBiZWNhdXNlIHdlIGhhdmUgYSBsb25nIGhpc3Rv cnkgb2YgZGV2ZWxvcGluZyBOQVQgdHJhdmVyc2FsIHRvb2xzIGxpa2UgU1RVTiwgVFVSTiwgb3Ig SUNFLg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0K From nobody Sat Jun 13 01:17: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 CC1931B2EF7 for ; Sat, 13 Jun 2015 01:17:23 -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 7Ax5fhKuC3gY for ; Sat, 13 Jun 2015 01:17:22 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::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 4FB141B2EF6 for ; Sat, 13 Jun 2015 01:17:22 -0700 (PDT) Received: by wifx6 with SMTP id x6so33778931wif.0 for ; Sat, 13 Jun 2015 01:17:20 -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=mYUbAbYm7SIRXinj2qHzjJY9EemofUB5Xlx0Yijr7Ew=; b=rWMehVr8mnvUim39BUU3D6dTXIVkoLWUhsj0k5HpbBAFjdzICyJczFgUBdyHEXkEgL MUqjdNKkPb+FRBOirnLgfG+t44u0F+BB0fY11f9Vqdb5sEtcYVmDjJtKcreelE66HAKc FFg1UlCT0OP3XFPB6VrwnF6XHtW6XY6fVnoCJeYJrFmn+uYqdv7jDKAbxZG7f51FTev2 iOEVGNmiJeN3BKf6JFKZEjnDvp0d8Ef/f9g6M44eHbYDZfmdl/YPxRvI9ZJbn4Tez+JV X7FQQYIkpMlrhETJS1kTVN2W25L3xlpfLQhPsMLPXkSpyOlCTNIW/+S9ZARVuXhrvTbM k1Kw== X-Received: by 10.194.187.170 with SMTP id ft10mr33753152wjc.26.1434183440843; Sat, 13 Jun 2015 01:17:20 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fm8sm6201878wib.9.2015.06.13.01.17.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jun 2015 01:17:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Sat, 13 Jun 2015 11:17:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150612143838.GJ27147@cisco.com> To: Tom Herbert X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Youjianjie , Christian Huitema , Martin Stiemerling , "mirja.kuehlewind@tik.ee.ethz.ch" , "spud@ietf.org" Subject: Re: [Spud] ??????: Numbers... 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, 13 Jun 2015 08:17:24 -0000 > On Jun 13, 2015, at 2:37 AM, Tom Herbert wrote: >=20 > On Fri, Jun 12, 2015 at 10:22 AM, Christian Huitema > wrote: >>> I have never heard 99% of UDP is trash to be true. Security folks in = Cisco told me >>> "a lot of unix networking apps from the 80th/90th based on UDP where >>> extremely insecure", and i think thats definitely true and has lead = the first wave >>> of firewalling off UDP. The second wave was p2p sharing apps which = also >>> caused a lot of enterprises to be weary of UDP and firewall it. >>=20 >> Two big applications that are running over UDP: voice and video with = Skype, video-games with Xbox Live. Of course, there are places where UDP = is blocked, in which case UDP applications will try tunneling over = HTTPS. But in the vast majority of consumer networks, these applications = use UDP just fine. >>=20 > Christian, >=20 > You present a very interesting datapoint, but I'm not sure how to > interpret it. Is UDP getting far reach now because most users are not > behind firewalls, firewalls are allowing all UDP to pass, or holes > have been commonly punched in firewalls for specific applications? > Would this imply there is less need to implement a UDP based protocol > to work with stateful firewalls? Most modern firewalls can recognize these different applications, so it = is possible to configure a firewall to let Skype or WebRTC through = without just allowing any and all UDP to pass. But the usual configuration for firewalls is to block the unknown. So = making something that is easy to recognize is definitely a good idea.=20 Yoav From nobody Tue Jun 16 01:13: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 A8C3E1A1A2C for ; Tue, 16 Jun 2015 01:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.612 X-Spam-Level: X-Spam-Status: No, score=-12.612 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 UhuiqH5bumWY for ; Tue, 16 Jun 2015 01:13:03 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72E21A0141 for ; Tue, 16 Jun 2015 01:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2912; q=dns/txt; s=iport; t=1434442373; x=1435651973; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5rl+ikr/stsms6KKPins+2uNPLeRqeYvu6wx/FhVrPI=; b=m+HE61z8tkU1BnWkfgSZRRzUDAZQgjkjUbNiYmTZKI4zwYo3flYySGlo YVfaKoFsh3DByJGc9jxYglb1V70L17VUmwNgliTZsZSSIlq3NNw6R0IcE IPVo580HbRbsBm/pRk1pQq777DrMAVEAp2MHHsQUIXLQTe9wnNnQWhU6J s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DIBwDv2X9V/5JdJa1bgxBUXwaDGKpWkCcJgVcKhG6BCgIcgRw4FAEBAQEBAQGBCoQiAQEBAwEBAQEgEToLBQsCAQgYAgImAgICJQsVEAIEDgWIJwgNtTqWcQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKI4UGB4JoL4EWBYVVjgYBi0GYECaDeW+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,624,1427760000"; d="scan'208";a="159883096" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 16 Jun 2015 08:12:52 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5G8CqVD012860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jun 2015 08:12:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 16 Jun 2015 03:12:52 -0500 From: "Pal Martinsen (palmarti)" To: Tom Herbert Thread-Topic: [Spud] ??????: Numbers... Thread-Index: AQHQpWjGIW3EgL0BBE6LvjQ/FRGinp2vIXsA Date: Tue, 16 Jun 2015 08:12:51 +0000 Message-ID: <486B9F34-9E47-4B74-B9DE-56BC9A3D84FA@cisco.com> References: <20150612143838.GJ27147@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.169.43] Content-Type: text/plain; charset="utf-8" Content-ID: <7482D5485915194CB52CAD791659ECEF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Youjianjie , Christian Huitema , Martin Stiemerling , "mirja.kuehlewind@tik.ee.ethz.ch" , "spud@ietf.org" Subject: Re: [Spud] ??????: Numbers... 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, 16 Jun 2015 08:13:04 -0000 DQo+IE9uIDEzIEp1biAyMDE1LCBhdCAwMTozNywgVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFu ZC5jb20+IHdyb3RlOg0KPiANCj4gT24gRnJpLCBKdW4gMTIsIDIwMTUgYXQgMTA6MjIgQU0sIENo cmlzdGlhbiBIdWl0ZW1hDQo+IDxodWl0ZW1hQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPj4+IEkg aGF2ZSBuZXZlciBoZWFyZCA5OSUgb2YgVURQIGlzIHRyYXNoIHRvIGJlIHRydWUuIFNlY3VyaXR5 IGZvbGtzIGluIENpc2NvIHRvbGQgbWUNCj4+PiAiYSBsb3Qgb2YgdW5peCBuZXR3b3JraW5nIGFw cHMgZnJvbSB0aGUgODB0aC85MHRoIGJhc2VkIG9uIFVEUCB3aGVyZQ0KPj4+IGV4dHJlbWVseSBp bnNlY3VyZSIsIGFuZCBpIHRoaW5rIHRoYXRzIGRlZmluaXRlbHkgdHJ1ZSBhbmQgaGFzIGxlYWQg dGhlIGZpcnN0IHdhdmUNCj4+PiBvZiBmaXJld2FsbGluZyBvZmYgVURQLiBUaGUgc2Vjb25kIHdh dmUgd2FzIHAycCBzaGFyaW5nIGFwcHMgd2hpY2ggYWxzbw0KPj4+IGNhdXNlZCBhIGxvdCBvZiBl bnRlcnByaXNlcyB0byBiZSB3ZWFyeSBvZiBVRFAgYW5kIGZpcmV3YWxsIGl0Lg0KPj4gDQo+PiBU d28gYmlnIGFwcGxpY2F0aW9ucyB0aGF0IGFyZSBydW5uaW5nIG92ZXIgVURQOiB2b2ljZSBhbmQg dmlkZW8gd2l0aCBTa3lwZSwgdmlkZW8tZ2FtZXMgd2l0aCBYYm94IExpdmUuIE9mIGNvdXJzZSwg dGhlcmUgYXJlIHBsYWNlcyB3aGVyZSBVRFAgaXMgYmxvY2tlZCwgaW4gd2hpY2ggY2FzZSBVRFAg YXBwbGljYXRpb25zIHdpbGwgdHJ5IHR1bm5lbGluZyBvdmVyIEhUVFBTLiBCdXQgaW4gdGhlIHZh c3QgbWFqb3JpdHkgb2YgY29uc3VtZXIgbmV0d29ya3MsIHRoZXNlIGFwcGxpY2F0aW9ucyB1c2Ug VURQIGp1c3QgZmluZS4NCj4+IA0KPiBDaHJpc3RpYW4sDQo+IA0KPiBZb3UgcHJlc2VudCBhIHZl cnkgaW50ZXJlc3RpbmcgZGF0YXBvaW50LCBidXQgSSdtIG5vdCBzdXJlIGhvdyB0bw0KPiBpbnRl cnByZXQgaXQuIElzIFVEUCBnZXR0aW5nIGZhciByZWFjaCBub3cgYmVjYXVzZSBtb3N0IHVzZXJz IGFyZSBub3QNCj4gYmVoaW5kIGZpcmV3YWxscywgZmlyZXdhbGxzIGFyZSBhbGxvd2luZyBhbGwg VURQIHRvIHBhc3MsIG9yIGhvbGVzDQo+IGhhdmUgYmVlbiBjb21tb25seSBwdW5jaGVkIGluIGZp cmV3YWxscyBmb3Igc3BlY2lmaWMgYXBwbGljYXRpb25zPw0KPiBXb3VsZCB0aGlzIGltcGx5IHRo ZXJlIGlzIGxlc3MgbmVlZCB0byBpbXBsZW1lbnQgYSBVRFAgYmFzZWQgcHJvdG9jb2wNCj4gdG8g d29yayB3aXRoIHN0YXRlZnVsIGZpcmV3YWxscz8NCj4gDQoNCg0KDQpUaGFua3MgQ3Jpc3RpYW4g Zm9yIHRoZSBkYXRhcG9pbnQuIEkgdGhpbmsgZW50ZXJwcmlzZSBudW1iZXJzIGFyZSBkaWZmZXJl bnQgKEkgYW0gYXNzdW1pbmcgdGhhdCBTa3lwZSBhbmQgWC1ib3ggYXJlIG5vdCB0eXBpY2FsbHkg ZW50ZXJwcmlzZSBhcHBsaWNhdGlvbnMpLiBCdXQgaXQgc2hvd3MgdGhhdCBtb3N0IGhvbWUgZXF1 aXBtZW50IHdvcmsgd2l0aCB0aGlzIGFwcHJvYWNoLCBhbmQgbm90aGluZyBpbiB0aGUgbWlkZGxl IG9uIHRoZSBiaWcgZGFyayBhbnMgc2NhcnkgSW50ZXJuZXQgYnJlYWtzIFVEUC4gVGhhdCBpcyB2 ZXJ5IHVzZWZ1bCBpbmZvcm1hdGlvbi4NCg0KU28gdGhlIHJlbWFpbmluZyBwcm9ibGVtIHNlZW1z IHRvIGJlIGVudGVycHJpc2UgbmV0d29ya3MgYW5kIHRoZSBmZWFycyBvZiBvcGVuaW5nIHVwIFVE UC4gQW5kIGhvcGVmdWxseSBzb21ldGhpbmcgU1BVRCBsaWtlIGNhbiBoZWxwIHdpdGggdGhhdC4N Cg0KLi0uDQpQw6VsLUVyaWsNCg0KDQo+IFRoYW5rcywNCj4gVG9tDQo+IA0KPj4gLS0gQ2hyaXN0 aWFuIEh1aXRlbWENCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gU3B1ZCBtYWlsaW5nIGxpc3QNCj4+IFNwdWRAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3B1ZA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3B1ZCBtYWls aW5nIGxpc3QNCj4gU3B1ZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwdWQNCg0K From nobody Tue Jun 16 02:15:58 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 2A0601A890D for ; Tue, 16 Jun 2015 02:15:57 -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 dGeOOXto8SqH for ; Tue, 16 Jun 2015 02:15:55 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 720561A88D7 for ; Tue, 16 Jun 2015 02:15:55 -0700 (PDT) Received: by wigg3 with SMTP id g3so102485231wig.1 for ; Tue, 16 Jun 2015 02:15:53 -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=0zjujsmeW6yAkYWk4uIqf5svuqicipX8Np+aBl+8LJg=; b=tJKUIq1nGJx+nFyDVeJYjAqeXfhZr8Pz2Zg4fsCjBcDcnGT4f8t0j2FY5oRuVnxSdM mjE4P3lmsZRELHV1aJ1y6xU3yK43hKwR9Roz/EVVHuV1pHy+bXjZJYceyglsAXzvE6Qr fOVBOFwDXEYRSDmeufjdHzezzjZ17SxhdeiWbzpWZ3l6IXslN0g4g/LPYL3HmTf7jOcl sVhAkm01F9ZN/A9pS0iEjJY5Yw1ct7S6IASnQcyYF268J5tJnITbk79fgZKKl4u9PvQ1 gP+j8LJiY9xrCbUY/mpWs/CsfWxIVpGhVLltWGsyDvcDNl0QjwwTf00QW6MRsp3b4HyD Lpww== X-Received: by 10.180.78.136 with SMTP id b8mr40433508wix.44.1434446153655; Tue, 16 Jun 2015 02:15:53 -0700 (PDT) Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ez19sm19818662wid.19.2015.06.16.02.15.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jun 2015 02:15:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <486B9F34-9E47-4B74-B9DE-56BC9A3D84FA@cisco.com> Date: Tue, 16 Jun 2015 12:15:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D5AE723-1D37-4F21-B697-9D3A4F58CEB7@gmail.com> References: <20150612143838.GJ27147@cisco.com> <486B9F34-9E47-4B74-B9DE-56BC9A3D84FA@cisco.com> To: "Pal Martinsen (palmarti)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Tom Herbert , Youjianjie , Martin Stiemerling , "mirja.kuehlewind@tik.ee.ethz.ch" , "spud@ietf.org" , Christian Huitema Subject: Re: [Spud] ??????: Numbers... 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, 16 Jun 2015 09:15:57 -0000 > On Jun 16, 2015, at 11:12 AM, Pal Martinsen (palmarti) = wrote: >=20 >>=20 >> On 13 Jun 2015, at 01:37, Tom Herbert wrote: >>=20 >> On Fri, Jun 12, 2015 at 10:22 AM, Christian Huitema >> wrote: >>>> I have never heard 99% of UDP is trash to be true. Security folks = in Cisco told me >>>> "a lot of unix networking apps from the 80th/90th based on UDP = where >>>> extremely insecure", and i think thats definitely true and has lead = the first wave >>>> of firewalling off UDP. The second wave was p2p sharing apps which = also >>>> caused a lot of enterprises to be weary of UDP and firewall it. >>>=20 >>> Two big applications that are running over UDP: voice and video with = Skype, video-games with Xbox Live. Of course, there are places where UDP = is blocked, in which case UDP applications will try tunneling over = HTTPS. But in the vast majority of consumer networks, these applications = use UDP just fine. >>>=20 >> Christian, >>=20 >> You present a very interesting datapoint, but I'm not sure how to >> interpret it. Is UDP getting far reach now because most users are not >> behind firewalls, firewalls are allowing all UDP to pass, or holes >> have been commonly punched in firewalls for specific applications? >> Would this imply there is less need to implement a UDP based protocol >> to work with stateful firewalls? >>=20 >=20 >=20 >=20 > Thanks Cristian for the datapoint. I think enterprise numbers are = different (I am assuming that Skype and X-box are not typically = enterprise applications). Skype (or equivalent) does get used in enterprises. X-box? Not as = much... > But it shows that most home equipment work with this approach, and = nothing in the middle on the big dark ans scary Internet breaks UDP. = That is very useful information. =E2=80=9CNothing" is perhaps too strong. As long as the UDP packets are = small enough, the big bad Internet will let it through, but there are = places where fragments are dropped. Not usually a problem for VoIP, but = could be for other applications. > So the remaining problem seems to be enterprise networks and the fears = of opening up UDP. And hopefully something SPUD like can help with that. Hopefully. But there=E2=80=99s also the coffee shop / hotel / public = transit networks that tend to have some very badly configured firewalls = with heavy-handed filtering.=20 Yoav (who works for a firewall vendor)= From nobody Sun Jun 28 23:57: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 014691A1B87 for ; Sun, 28 Jun 2015 23:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 2K7QobjWF3Pk for ; Sun, 28 Jun 2015 23:57:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684EA1A1B86 for ; Sun, 28 Jun 2015 23:57:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYC37079; Mon, 29 Jun 2015 06:57:20 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 07:57:20 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.68]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 14:57:14 +0800 From: Youjianjie To: "spud@ietf.org" Thread-Topic: New Version Notification for draft-yw-spud-use-cases-00.txt Thread-Index: AQHQsjdLzpnDJY98rUaHIObXYHXzMJ3DCkRg Date: Mon, 29 Jun 2015 06:57:13 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Spud] Fwd: New Version Notification for draft-yw-spud-use-cases-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: Mon, 29 Jun 2015 06:57:25 -0000 RGVhciBhbGwsDQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHR3byBzcGVjaWZpYyBTUFVEIHVz ZSBjYXNlcywgaS5lLiBmaXJld2FsbCBhbmQgVENQIG9wdGltaXphdGlvbi4gDQpZb3VyIGNvbW1l bnRzIGFyZSBhcHByZWNpYXRlZC4gDQoNClRoYW5rcywNCkppYW5qaWUgJiBKYWNraWUNCg0KLS0t LS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0 NuaciDI55pelIDE0OjQ2DQrmlLbku7bkuro6IFlvdWppYW5qaWU7IFdlaXhpbnBlbmcgKEphY2tp ZSk7IFdlaXhpbnBlbmcgKEphY2tpZSk7IFlvdWppYW5qaWUNCuS4u+mimDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC15dy1zcHVkLXVzZS1jYXNlcy0wMC50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteXctc3B1ZC11c2UtY2FzZXMtMDAudHh0IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmlhbmppZSBZb3UgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQteXctc3B1ZC11c2UtY2FzZXMNClJldmlz aW9uOgkwMA0KVGl0bGU6CQlVc2UgQ2FzZXMgZm9yIFNQVUQNCkRvY3VtZW50IGRhdGU6CTIwMTUt MDYtMjgNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTgNClVSTDogICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteXctc3B1 ZC11c2UtY2FzZXMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQteXctc3B1ZC11c2UtY2FzZXMvDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXl3LXNwdWQtdXNlLWNhc2VzLTAwDQoNCg0K QWJzdHJhY3Q6DQogICBUaGUgcHVycG9zZSBvZiBTUFVEIGlzIHRvIHByb3ZpZGUgYSBzdGFuZGFy ZGl6ZWQgbGF5ZXIgYmVsb3cgdGhlDQogICB0cmFuc3BvcnQgbGF5ZXIsIHRvIGJlaGF2aW9yIGFz IGEgY29tbXVuaWNhdGlvbiBjaGFubmVsIGJldHdlZW4gdGhlDQogICBob3N0IGFuZCBuZXR3b3Jr IGRldmljZXMuICBTbyB3aGVuIGEgbmV3IHRyYW5zcG9ydCBwcm90b2NvbCBpcw0KICAgZGVwbG95 ZWQsIGl0J3MgZWFzeSBmb3IgbmV0d29yayBkZXZpY2VzIHRvIGNvb3BlcmF0ZSB3aXRoIGl0LiAg TmV3DQogICB0cmFuc3BvcnRzIGNvdWxkIGhhdmUgYSBjb21tb24gZW5jYXBzdWxhdGlvbiB0byBt aWRkbGVib3hlcy4gIE9uIHRoZQ0KICAgb3RoZXIgaGFuZCwgdGhlIHRyYW5zcG9ydCBsYXllciBj b3VsZCBhbHNvIG1ha2UgdXNlIG9mIHRoZSBzdGF0ZSBvZg0KICAgbmV0d29yayBkZXZpY2VzIGNv bGxlY3RlZCBieSB0aGUgU1BVRCwgdG8gaW1wcm92ZSB0cmFuc3BvcnQNCiAgIHBlcmZvcm1hbmNl Lg0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHNvbWUgZXhlbXBsYXJ5IHVzZSBjYXNlcyBm b3IgU1BVRCwgZXNwZWNpYWxseQ0KICAgaW4gc3RhdGVmdWwgZmlyZXdhbGwgYW5kIFRDUCBvcHRp bWl6YXRpb24uICBUaGUgb2JqZWN0aXZlIG9mIHRoaXMNCiAgIGRyYWZ0IGlzIG5vdCB0byBjb3Zl ciBhbGwgY29uY2VpdmFibGUgcDJhIG9yIGEycCBzaWduYWxpbmcgaW4gZGV0YWlsLg0KICAgUmF0 aGVyLCB0aGUgaW50ZW50aW9uIGlzIHRvIGV4cGxhaW4gdGhlIHJlcXVpcmVtZW50cyBpbiB0aGVz ZSB1c2UNCiAgIGNhc2VzIGFzIGZhciBhcyBpdCBpcyByZXF1aXJlZCB0byBjb21wbGVtZW50IHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBvZg0KICAgdGhlIFNQVUQuDQoNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K