Internet protocols are changing
blog.apnic.net
blog.apnic.net
> It’s necessary to prevent ossification, to ensure that protocols can evolve to meet the needs of the Internet in the future; otherwise, it would be a ‘tragedy of the commons’ where the actions of some individual networks — although well-intended — would affect the health of the Internet overall.
On the other hand, I've done a fair bit of work getting TCP based applications to behave properly over high latency high congestion (satellite or radio usually) links and QUIC makes me nervous. In the old days you could put a TCP proxy like SCPS in there and most apps would get an acceptable level of performance, but now I'm not so sure. It seems like everybody assumes you're on a big fat broadband pipe now and nobody else matters.
This is intentional. The powers that be have an interest in moving everyone to faster networks, and they effectively control all new web standards, and so build their protocols to force the apps to require faster, bigger pipes. This way they are never to blame for the new requirements, yet they get the intended benefits of fatter pipes: the ability to shove more crap down your throat.
It's possible to cache static binary assets using encrypted connections, but I am not aware of a single RFC that seriously suggests its adoption. It is also to the advantage of the powers that be (who have the financial means to do this) to simply move content distribution closer to the users. As the powers that be don't provide internet services over satellite or microwave, they do not consider them when defining the standards.
Google is effectively the actual determiner of Internet standards. As the article notes, Google implemented QUIC on their servers and their browsers, and therefore, 7% of Internet traffic is already QUIC-based, despite it not being officially accepted at this point. This is essentially the same as what happened with SPDY at the time.
As Google controls both the primary source of Internet traffic (up to 35-40% of all Internet traffic, depending who you ask, and a browser share in the what 65% range), Google can implement any new protocol it wants, and everyone else needs to support it or be left out.
Arguably, the IETF is no longer the controlling organization here: Google is. Should the IETF not approve Google's proposals, Google will continue to use them, and everyone else will continue to need to support them.
As the parent notes, Google both essentially determines these standards, and has an interested in faster networks so they can shove fatter payloads down the pipe. This is in part due to the ability to implement pervasive tracking, and of course, they operate a lot of content distribution products like YouTube.
Note that every method here that makes it harder for governments to censor and ISPs to prioritize also makes it harder for people to detect, inspect, and filter out Google's pervasive surveillance.
Right now, I'm convinced we need Google's help to make it harder for governments and ISPs to censor and prioritize.
After that, we'll deal with Google.
The good part is that it focus on fixing the government. That's the correct entity to fix.
We can talk about network neutrality whatever we want - but these companies have built technological capabilities to have "little bit bigger share".
So, probably after some time it is too late to deal with Google:)
What is your preferred course here? Google has provided free as in freedom source code for all of the above, and in some cases pushed the code upstream. Granted, it will take small players longer to see the benefits of these techs, since they can't afford to integrate it themselves and must wait for vendors to include it. But small players usually have worse user experience regardless of the mechanism. Proposed standards are just one way that happens.
I think it's far more important to deal with Google than hand them the keys to the kingdom while fighting smaller fish.
I do think it's important to say that this isn't a sure-fire deal. We had stuff like NaCl (native code in the browser) that basically died off, and other options as well.
Inversely, SPDY is not what the standard is, and Google instead pulled stuff it learned into HTTP/2. This seems like a positive aspect to me.
It's important to be wary of things that Google won't bring up, but overall I feel like we're getting a lot of benefit from having an implementer "beta test" stuff in this way.
Designing a new protocol to be used at internet scale is really hard. Having the ability to test that on a significant amount of traffic before refining and standardizing is a huge advantage that few groups on the planet are able to make use of. From the IETF's perspective, I would look skeptically upon a new standard that someone dreamed up but had little to no practical real-world data to show how it behaves in practice.
But I also want them to avoid ramming standards down the IETF's throat. If, after due consideration, the IETF says "no" to a new standard, I want Google to stand down and abandon it. If the IETF thinks it's a good idea and is willing to work with Google to iron out issues and standardize in a public manner, then that's the ideal outcome.
Google using the standards process to release new things is exactly what we should want and see. You make it like it is some nefarious behavior. Geeze.
Google has offered things for standards which were changed by the standards group and Google adopted the change.
Google could just keep it all closed if they want. Honestly wonder if they will not in the future with posts like yours. Why do it?
For more info, read this: https://www.webcitation.org/5shCiXna8
A noteworthy quote:
> In those few places where network upgrades are not practical, QoS deployment is usually even harder (due to the high cost of QoS-capable routers and clueful network engineers). In the very few cases where the demand, the money, and the clue are present, but the bandwidth is lacking, ad hoc approaches that prioritize one or two important applications over a single congested link often work well. In this climate, the case for a global, interdomain Premium service is dubious.
"Premium service" in this document refers, basically, to an upgraded Internet with additional rules to provide quality of service for congested links.
(I'm not personally claiming that all these conclusions are correct and that they still apply today, just that there's some backstory here.)
I think there'll be a few answers to the problem - first, it'll be slow to impact many of the kinds of users currently using Satellite, second for web apps it's either internal (so they can define transport) or external (in which case they are, or can, use a proxy and continue tcp/http over the sat links.
Later on I expect we'll get gateways (in the traditional sense) to sit near the dish ... though I also would expect that on that timeframe you'll be seeing improvements in application delivery.
Ultimately I hope - hubris, perhaps - that the underlying problem (most of our current application performance issues are because apps have been written by people that either don't understand networks, or have a very specific, narrow set of expectations) will be resolved. (Wrangling CIFS over satellite - f.e.)
It's so normalized I figured there wasn't a whole lot I could do about it, until I noticed Nine sync'ing my Exchange inbox from scratch for something like 3MB. Then I noticed Telegram had used 3MB for a month's regular use, while Hangouts had used 10MB for five minutes of use.
Despite living in the first world, I'm kind of excited for Android's Building for Billions. There's so much flagrant waste of traffic today, assuming as you say that you have a big fat broadband pipe, with no thought to tightly metered, high latency, or degraded connections.
(I switched to an inexpensive mobile plan with 500MB, you see)
The only demonstrable needs are bugfixes and significant advances because inventing and imposing complexity in all implementations or damaging backwards compatibility are insanely costly in terms of retooling, redeployment, customer interruptions, advertising, learning curve, interop bugs and attack surfaces.
Often, Google sites serving via QUIC are the only sites I can load. I can load HTML5 YouTube videos despite not being able to open the linkedin.com homepage. Stability for loading HTTP over QUIC in my experience is very comparable to loading HTTP over OpenVPN (using UDP) with a larger buffer.
For example, you mention latency, but QUIC is supposed to remove unnecessary ordering constraints, which could eliminate round trips and help with latency.
https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
It may be built on top of IP, but TCP / UDP levels are important for NAT and such. Too few people use DMZ and other features of routers / firewalls. Its way easier to just put up with TCP / UDP issues to stay compatible with most home setups.
However, the high turnover for mobile phones has allowed more aggressive changes to the networking stack. Perhaps this, in addition to IPv6, would make something like SCTP easier to adopt widely?
I dove into the world of curve fitting (wee!) and my prediction[1] for 95% IPv6 adoption is around the year 2025: https://imgur.com/a/LyBJn (fitted to the logistic curve[2], x=0 is basically 2010, y is percent adoption)
[1] Which you should completely trust because I've been doing this for all of 20 minutes!
[2] https://en.wikipedia.org/wiki/Logistic_function#In_economics...
Lets say 20% adoption means we're 40% of the way through the transition. The slope for IPv6 looks better and better every day, but overall it's not a great adoption story for tech that inevitably has to happen. (not to discourage or minimize the all the hard work done in getting IPv6 this far)
I assume workplaces have a lower adoption rate due to enterprise inertia. Or is there another explanation?
The last dogleg was January 2015. And since then it’s been linear (with a little stall this month) at about 5% of the Internet converting per year. That’s another 15 years to convert the rest, unless there’s a new dog leg up.
Also percentages don’t work the way humans think they do. Especially when the number of devices is constantly climbing. That may just indicate that some fraction of new hardware is ipv6 but little old hardware is being updated.
We may well have ~2 billion machines on ipv4 pretty much indefinitely, slowly being diluted by addition of new hardware.
The economics going forward will be interesting. I've seen some low-end VPSes charge a lower rate for machines that are IPv6-only.
https://www.ietf.org/proceedings/48/I-D/sigtran-sctptunnel-0...
Home routers is another matter, home users don't make conscious decision about it, but in my experience UDP works just fine (because a lot of games use it) and it should be good enough for any protocol.
You might say that they're clueless and shouldn't be allowed near networking equipment (and you might even be right) but it's not going to change a thing. For the foreseeable future, working around broken environments is all we can do.
("Getting through broken routers" is certainly a significant advantage; I'm just asking if that's the only good reason to not build directly on IP.)
What allocating a new IP protocol says is pretty close to "all bets are off, and we're carefully taking responsibility for how every system that interacts with TCP/IP headers will handle these packets". Since SCTP doesn't need that, there's no upside. It's vanity and bloody-mindedness.
So you end up with a chicken-and-egg problem: router manufacturers aren't going to add support for it unless there's sufficient demand, and there can't be sufficient demand because very few people can use and rely on it.
Firewalls -- whose firewalls are we talking about here? If a client (say, home user) tries to initiate an SCTP connection to a server somewhere, what step will fail?
Because they have to do NAT, at least on IPv4.
> Firewalls -- whose firewalls are we talking about here? If a client (say, home user) tries to initiate an SCTP connection to a server somewhere, what step will fail?
Because the connection tracking that's needed to even recognize whether a packets belongs to an outbound or an inbound connection needs to understand the protocol.
Of course, they can still block or throttle by IP, so the next step is to increase deployment of content-centric networking systems.
Perhaps our best weapon against Internet rent seekers and spooks is technical innovation.
It is astonishing to me that Google can invent QUIC, deploy it on their network+Chrome and boom! 7% of all Internet traffic is QUIC.
Traditional HTTP over TCP and traditional DNS are becoming a ghetto protocol stack; analysis of such traffic is sold to who knows whom, the content is subject to manipulation by your ISP, throttling is trivial and likely to become commonplace with Ajit Pai et al. Time to pull the plug on these grifters and protect all the traffic.
Correct. Middleboxes should be presumed hostile; if you control the endpoints you can install a MITM CA, but it's safer to put what you want directly on the endpoint.
So if an app is hostile (say, all the Google apps), then I have no way to intercept their traffic anymore.
And you can put your CA into the system CA store if you have root. (You can make an Android image, so technically the requirement is unlocked - unlockable - bootloader.)
Apps can and will refuse to run in that situation.
Modifying /system will make every SafetyNet check fail, as result Netflix, Snapchat, Google Play Movies, and most banking apps will refuse to run.
I can decide to install the app or not? How do I go about replacing Google's system apps with my own, without preventing above mentioned apps from running? I can't. And I can't buy reasonable devices withou Google Android, due to the non-compete clause in the OEM contracts.
http://www.androidpolice.com/2017/07/16/safetynet-can-detect...
You can walk into your bank and access the services. Or call them. Or use their browser based service, right?
Google and a lot of developers made the choice to restrict user freedom for more security.
I don't agree with it, but it's what it is. A trade off.
Of course, you can sign your own images and put the CA into the recovery DB and relock the bootloader on reasonable devices. ( https://mjg59.dreamwidth.org/31765.html )
Or at least you used to be able to.
Either the user controls the program, or the program controls the user.
Think Netflix/Comcast.. no hiding what that traffic is.
If you don't think about it, it may seem that way. But until everyone sends all their data over tor, or some other system that obscures which IP you're trying to get to, it's still easy to filter.
There's (within epsilon of) zero motion I've seen towards obscuring IP addresses, for good reason.
The DNS-over-http discussion in this post mention that in passing, though I wonder if this treatment might not be worse than the disease.
https://news.ycombinator.com/item?id=8404788
https://news.ycombinator.com/item?id=8550133
I quote myself: “It really is no surprise that Google is not interested in this, since Google does not suffer from any of those problems which using SRV records for HTTP would solve. It’s only users which could more easily run their own web servers closer to the edges of the network which would benefit, not the large companies which has CDNs and BGP AS numbers to fix any shortcomings the hard way. Google has already done the hard work of solving this problem for themselves – of course they want to keep the problem for everybody else.”
365 is not just the browser suite
What are you referring to here?
Essentially every geek I have ever talked to support standards, decentralization, community efforts etc. Yet, here we have the company that has more influence than anyone else over the Internet almost single-handedly designing the protocol.
Personally, I'd say it was first spurred by Firesheep back in 2010, but the idea of encrypting all websites, even content-only websites may have been Snowden related.
DNS over HTTP is a prime example: blocking outbound DNS for all but a few resolvers, and monitoring the hell out of the traffic on those resolvers is a big win for enterprise networks. What the RFC calls hostile "spoofing" of DNS responses enterprise defenders call "sinkholing" of malicious domains. Rather than trying to add a layer of validation to DNS to provide the end user with assurance that the DNS request they got really is the name they asked for (and, in theory, allow the enterprise to add their own key to sign sinkhole answers) instead DOH just throws the whole thing out...basically telling enterprise defenders "fuck your security controls, we hate Comcast too much to allow anyone to rewrite DNS answers."
"Fuck your security controls, we hate Comcast" is, I think, a bad philosophy for internet-wide protocols. (That's basically what the TLS 1.3 argument boils down to also...and that's a shame.)
Forging DNS responses is a horrible idea (and already breaks with DNSSEC). I have a hard time to comprehend how this can be considered a reasonable security measure.
OK, let's walk it through.
Task: block access to "attacker.com" and all it's subdomains. Reason: Maybe it's a malware command and control, maybe it's being used for DNS tunneling, whatever. Blocking a domain that's being used for malicious behavior is a reasonable thing for an enterprise to want to accomplish.
Option 1: Block by IP at the firewall. Problems: Attackers can simply point the domain to another IP, so you're constantly playing whack-a-mole and constantly behind the attacker. Also, if it's a DNS tunnel the DNS answer is what's interesting, not the traffic to the actual IP. Result: Fail, doesn't solve the problem.
Option 2: Block by DNS Name at the firewall. Problems: Requires the firewall to understand the protocols involved, which they have shown themselves to be inconsistent at, at the best of times. Also, doing regex on every DNS query packet(in order to find all subdomains) doesn't scale. Result: Fail, doesn't scale.
Option 3: Block with local agent. Problems: Tablets, phones, appliances, printers can't run a local agent. Result: Fail. Not complete coverage
Option 4: Block outbound DNS except for approved resolvers, give those resolvers an RPZ feed of malicious domains. Problem: Clients have to be configured to use those resolvers, but otherwise none. Result: Pass. It's standards compliant, and DNSSec isn't an issue since the resolver never asks for the attackers DNS answer, so they never get the chance to offer DNSSec.
That's why option 4 (or some variant of it) is popular in enterprises. It accomplishes the task in a standards-compliant way, and covers the entire enterprise in a way that scales well.
DOH blows this up. So, the question becomes: in a world with DOH, how is an enterprise supposed to completely and scalably block access to "attacker.com" and all its subdomains? So far, the answer has been "you don't." I think that is a really shitty answer to someone who's trying to accomplish something reasonable.
The one-size-fits-all answer with DOH is the same as without it: Tell your devices to use/trust the MitM.
Most nativity support it now.
Which will result in all of Google being blocked by schools, businesses, and entire nations. Which, as Google is relied upon more and more, means less access to things like mail, documents, news, messaging, video content, the Android platform, etc.
Thanks.
A huge number of them are absolutely reliant on Google, for things like (org-wide) Google Mail, Google Docs, ChromeBook deployments, and so on -- not to mention basic Google search.