From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 500873B2A4 for ; Fri, 15 Dec 2017 12:18:03 -0500 (EST) Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 13CA8252C7; Fri, 15 Dec 2017 12:18:03 -0500 (EST) Received: from app10.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EB99725280; Fri, 15 Dec 2017 12:18:02 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app10.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 15 Dec 2017 12:18:03 -0500 Received: from reed.com (localhost.localdomain [127.0.0.1]) by app10.wa-webapps.iad3a (Postfix) with ESMTP id DBA02E0D5F; Fri, 15 Dec 2017 12:18:02 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 15 Dec 2017 12:18:02 -0500 (EST) X-Auth-ID: dpreed@reed.com Date: Fri, 15 Dec 2017 12:18:02 -0500 (EST) From: dpreed@reed.com To: "cerowrt-devel@lists.bufferbloat.net" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20171215121802000000_11621" Importance: Normal X-Priority: 3 (Normal) X-Type: html Message-ID: <1513358282.897128026@apps.rackspace.com> X-Mailer: webmail/12.9.10-RC Subject: [Cerowrt-devel] =?utf-8?q?Random_thought_-_reactions=3F?= X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 17:18:03 -0000 ------=_20171215121802000000_11621 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThe disaster in the FCC's move to reverse the Open Internet Order will p= robably continue.=0A =0AAs some of you may know, but most probably don't, I= have a somewhat nuanced view of the best way to preserve what is called ne= twork neutrality. That's because I have a precise definition of what the In= ternet architecture is based on. Essentially, access providers (or for that= matter anyone who stands between one part of the Internet and another) sho= uld forward packets as specified in the IPv4 or IPv6 header, with best effo= rts. In particular, that means: meet the protocol specification of the IP l= ayer, base routing, queueing, and discarding only on the information therei= n contained. "Best efforts" does not mean queueing or discarding packets se= lectively based on addresses or protocol. However, ToS can be used.=0A =0AI= t turns out that the Open Internet Order pretty much matched that definitio= n in effect.=0A =0ABut we are about to enter a new age, where arbitrary con= tent inspection, selective queueing, and modification are allowed at the ac= cess provider switching fabric. Based on any information in the packet. Als= o, data collection and archiving of content information (e.g. wiretapping) = is likely to be OK as well, as long as the data is "protected" and there is= a contract with the customer that sort of discloses the potential of such = collection.=0A =0ACompanies like Sandvine, Ellacoya, Phorm, NebuAd and more= modern instantiations will be ramping up production of "Deep Packet Inspec= tion" gear that can be customized and deployed by access providers. (10-15 = years ago they ramped up to sell exactly this capability to access provider= s).=0A =0AI have never viewed the FCC rulemaking approach as the right way = for the Internet to deal with this attack by one piece of the transport net= work on the integrity of the Internet architecture as a whole. However, it = was a very practical solution until now.=0A =0ASo I've been thinking hard a= bout this for the last 15 years.=0A =0AThe best and most open Internet we h= ad for end users was available when the Internet was "dialup". That include= s modems, ISDN digital, and some DSL connectivity to non-telco POPs. There = was competition that meant that screwing with traffic, if detected, could b= e dealt with by switching what were then called ISPs - owners of POPs. This= died when Cable and Telco monopolies eliminated the POPs, and made it impo= ssible to decide where to connect the "last mile" to the Internet.=0A =0ASo= can we recreate "dialup"? Well, I think we can. We have the technical ing= redients. The key model here is IPv6 "tunnel brokers" (I don't mean the spe= cific ones we have today, which are undercapitalized and not widely dispers= ed). Today's Home Routers (minus their embedded WiFi access points) could b= e the equivalent of ISDN modems.=0A =0AWhat we need is to rethink the way w= e transport IP packets, so that they are not visible or corruptible by the = access provider, just as they were not visible or corruptible by the phone = company during the "dialup" era.=0A =0AI don't think I am the first to thin= k of this. But the CeroWRT folks are a great resource for one end of this, = if there were companies willing to invest in creating the POPs. I know of s= ome folks who might want to capitalize the latter, if there would be a retu= rn on investment.=0A =0AUnder the Open Internet Order, there was no meaning= ful potential of a return on investment. Now there is.=0A =0AI think the mi= ssing piece is a "stealth" approach to carrying packets over the access pro= vider's link that cannot be practically disrupted by DPI gear, even very hi= gh speed gear with good computing power in it. That involves encryption and= sort-of-steganography. Tor can't solve the problem, and is not really need= ed, anyway.=0A =0AAnyway, I have some protocol ideas for transporting arbit= rary IPv6 and IPv4 packets to POPs, and some ideas for how to evolve POPs i= n this novel context.=0A =0AI'm interested in thoughts by the CeroWRT devel= opers. Not just technical thoughts, but practical ones. And especially "ser= vices" that such POP operators could offer that would allow them to charge = a bit of cost/profit, on top of the basic access provider services that wil= l be needed to reach them.=0A =0ABTW, the same applies to cellular, where I= think the problem of breaking the Internet architecture will be a lot wors= e. We need to make cellular Internet access more like "dialup". ------=_20171215121802000000_11621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The disaster in th= e FCC's move to reverse the Open Internet Order will probably continue.

= =0A

 

=0A

As some of yo= u may know, but most probably don't, I have a somewhat nuanced view of the = best way to preserve what is called network neutrality. That's because I ha= ve a precise definition of what the Internet architecture is based on. Esse= ntially, access providers (or for that matter anyone who stands between one= part of the Internet and another) should forward packets as specified in t= he IPv4 or IPv6 header, with best efforts. In particular, that means: meet = the protocol specification of the IP layer, base routing, queueing, and dis= carding only on the information therein contained. "Best efforts" does not = mean queueing or discarding packets selectively based on addresses or proto= col. However, ToS can be used.

=0A

 

=0AIt turns out that the Open Internet Order pretty much = matched that definition in effect.

=0A

 

= =0A

But we are about to enter a new age, where arbitr= ary content inspection, selective queueing, and modification are allowed at= the access provider switching fabric. Based on any information in the pack= et. Also, data collection and archiving of content information (e.g. wireta= pping) is likely to be OK as well, as long as the data is "protected" and t= here is a contract with the customer that sort of discloses the potential o= f such collection.

=0A

 

=0A

Companies like Sandvine, Ellacoya, Phorm, NebuAd and more modern i= nstantiations will be ramping up production of "Deep Packet Inspection" gea= r that can be customized and deployed by access providers. (10-15 years ago= they ramped up to sell exactly this capability to access providers).

= =0A

 

=0A

I have never = viewed the FCC rulemaking approach as the right way for the Internet to dea= l with this attack by one piece of the transport network on the integrity o= f the Internet architecture as a whole. However, it was a very practical so= lution until now.

=0A

 

=0A

So I've been thinking hard about this for the last 15 years.

=0A=

 

=0A

The best and mos= t open Internet we had for end users was available when the Internet was "d= ialup". That includes modems, ISDN digital, and some DSL connectivity to no= n-telco POPs. There was competition that meant that screwing with traffic, = if detected, could be dealt with by switching what were then called ISPs - = owners of POPs. This died when Cable and Telco monopolies eliminated the PO= Ps, and made it impossible to decide where to connect the "last mile" to th= e Internet.

=0A

 

=0A

=0A

&nbs= p;

=0A

What we need is to rethink the way we trans= port IP packets, so that they are not visible or corruptible by the access = provider, just as they were not visible or corruptible by the phone company= during the "dialup" era.

=0A

 

=0A

I don't think I am the first to think of this. But the Cero= WRT folks are a great resource for one end of this, if there were companies= willing to invest in creating the POPs. I know of some folks who might wan= t to capitalize the latter, if there would be a return on investment.

= =0A

 

=0A

Under the Ope= n Internet Order, there was no meaningful potential of a return on investme= nt. Now there is.

=0A

 

=0A

I think the missing piece is a "stealth" approach to carrying packe= ts over the access provider's link that cannot be practically disrupted by = DPI gear, even very high speed gear with good computing power in it. That i= nvolves encryption and sort-of-steganography. Tor can't solve the problem, = and is not really needed, anyway.

=0A

 

= =0A

Anyway, I have some protocol ideas for transporti= ng arbitrary IPv6 and IPv4 packets to POPs, and some ideas for how to evolv= e POPs in this novel context.

=0A

 

=0A

I'm interested in thoughts by the CeroWRT developers. N= ot just technical thoughts, but practical ones. And especially "services" t= hat such POP operators could offer that would allow them to charge a bit of= cost/profit, on top of the basic access provider services that will be nee= ded to reach them.

=0A

 

=0A

BTW, the same applies to cellular, where I think the problem of br= eaking the Internet architecture will be a lot worse. We need to make cellu= lar Internet access more like "dialup".

=0A ------=_20171215121802000000_11621--