Hacker News Reader

I've been out of the industry for awhile, and skimmed through the article, and I don't know that either of the problems would occur. It really depends how the idea is turned into a specification, as approved by a standards body from industry.

The way QoS works for VoLTE for example, is not by putting application layer knowledge at the link layer. Instead the services that activate and route a phone call, have the ability to send a rule, called a traffic flow template, to the underlying LTE network. The flow template is a description of a flow from/to the device, that then has the transport network apply the expected scheduling behavior. I want a guaranteed 15 kbps for real-time voice, the LTE network can then use to coordinate radio scheduling, prioritize against background bulk transfers, block handoffs to cell towers that wouldn't have enough capacity, etc.

In concept this would work with fully end to end encrypted video and chat (I left the industry before the encrypted side was rolled out). I suspect some might argue the flow template itself leaks information about the data, but an observer of the network traffic can likely glean similar information, a steady flow of small packets is probably voice traffic type of idea. This just gives the network enough information to identify a flow and control for how to schedule the packets.

The biggest restriction is rollout and integrating with external services. Needs agreements between companies, restrictions on abuse, etc, etc.

Anyways, I don't think what is being proposed necessitates the problems. It'll really depend on what the standards bodies decides to do.

> The way QoS works for VoLTE for example, is not by putting application layer knowledge at the link layer. Instead the services that activate and route a phone call, have the ability to send a rule, called a traffic flow template, to the underlying LTE network.

So you need to put link-layer knowledge in the application layer, and on anything in between the app and the network link. Your app needs some API to do this, and it surely isn't a transparent connect(2). And if you want full support, then when hook up your LTE access point to a consumer-grade wifi-router — or maybe your business's router, as a backup if the primary link fails — you'll need some way to relay support there as well, and to your desktop software running Windows, and to OSX and Linux, and your Docker container.

It's all doable, it's just a massive amount of coordination in exactly the way "throw me some packets!" isn't.

> So you need to put link-layer knowledge in the application layer, and on anything in between the app and the network link. Your app needs some API to do this, and it surely isn't a transparent connect(2).

Well let's not lose sight of the problem being solved here. If I'm a phone operator, I don't want someone downloading bittorrent on the same cell to cause packet loss and garble my phone call so it's unusable. Throwing some packets over the fence doesn't tend to work so well when there are constraints on the magic tubes.

If the link layer knows that the encrypted bits are actually transporting video, then an attacker might have an easier time decrypting the traffic.

Perhaps – but well-compressed video is hard to distinguish from noise. You should already be assuming the attacker knows that kind of thing; googlevideo.com doesn't serve much other than video, for example.

No. That's implying your hardware has knowledge of cultural or human constructs. Your ascribing a set of qualities to a hunk of silicon you darn well have no business doing. Besides which, say googlevideo.cim flubs the Domain renewal and I snap it up and start serving a Slackware mirror for instance. The Stack below the application layer should neither care nor assume anything other than "take this, send here" with maybe some wiggle room where I have the option to tell it "best effort is okay" or "make it reliable".

Anything else is biasing certain uses for certain endpoints, which strikes me as digital fiefdom carving. No thanks. Dumb pipes, generously provisioned, thank you very much.

> No. That's implying your hardware has knowledge of cultural or human constructs.

Once upon a time I was working at a startup which pivoted slightly from generic "store analytics" to a product which mirrored the wifi network's uplink to a server where we would do deep packet inspection and watch you price-compare on Amazon (at the time, checkout was encrypted, but browsing and Add to Cart were unencrypted, and Amazon was offering discounts for price-comparing in store.) It was alluded to in the wifi network privacy policy that you didn't read. I understand that, in the days since I got creeped out and left, several hardware vendors have since added support in their equipment to facilitate the operation of these analytics.

We are fortunate that so much more is encrypted today, but pay heed! You must assume that hardware participates in a system that knows about human constructs, in all the most adversarial ways possible.

I wish someone would use that data and actually price match amazon. I hate trying to buy non counterfeit items on the vendor site only to b find out that they are 20-30% more after after shipping. Usally I give up at that point out risk amazon counterfeit.

You know, I die a bit inside everytime I find something like this out.

This is why we can't have nice things.

However... This is still markedly different than baking in heuristic, application specific optimizations into the hardware transport and lower levels. At that point, who sends what where should be a foregone conclusion. No hardware manufacturer should even be thinking of accommodating this niche case or that. I mean, they are free to, but everything I've seen says that isn't the best idea.

Leave it to the Application layer to optimize.

This isn't true. Good encryption makes it impossible to derive the decryption key even if you have a large selection of the plaintext.

Otherwise, an attacker could decrypt web traffic, knowing that a lot of the data is ASCII text.

All encryption is good until it's not.

Homomorphic encryption could be of use here if there is meta data for the encrypted content, but I also don't see the direct benefit to let a low level transmitter manipulate contents.

Deep packet inspection is still a security flaw in my opinion. For me it destroyed the chain of trust. I know that practical application to inspect the next trojan an employee downloads through https, but I believe interception should be done after the download (before anything is executed of course).

What's the point of homomorphic encryption if you can still see how the behaviour changes? You might as well just make the desired behaviour public and don't bother with trying to somehow get something to read sensitive data and change its behaviours accordingly without leaking information about the data (which is not feasible, no matter how advanced your encryption).

You're talking about homomorphic encryption of metadata?

If so, I'm not sure I get it. If the infrastructure has to make prioritization decisions for certain types of traffic, I think it just needs to know the type of traffic. If it's "encrypted", but has an obvious end target of the computation, than it's not really encrypted.

No, the metadata would not be encrypted, so that you know which operations would be sensible. Just homomorphic encryption to do these operations without the sender being able to decrypt the respective data. Don't have any particular use cases at hand though. Brightening an image without being able to decrypt it or something like that...?

I don’t see it to be the general premise of the article. If anything, Shannon’s original work from 1948 seems to lie at the heart of the premise.

Problem 1: OSI leads to a lot of energy inefficiency. It was formulated in a world where networks were small and climate change was not a major concern. Cross-layer protocol/tech can and should be more easily deployable. The common issue with this and IPv6 is the inability to deploy new stuff on an incremental basis without breaking its core connectivity functionality.

Problem 2: Again, I think the article does not specifically call for this. This could be _a_ way to do this. One could do other things that are a cooperation between tx and rx which would also convey the meaning to rx effectively.

The article explains that machine learning techniques would likely be used. The transmitter doesn’t have to know your content to recognize that a certain stream has been flowing from A to B within a certain bandwidth. It could also recognize dropouts or delays in such transmission and prioritize the data when it finally comes through. There’s nothing wrong with that.

Or more simply, the sender could request a specific traffic bandwidth or pattern as part of initiating the connection.

The OSI model isn’t a hard requirement. We already have things like QoS which are commonly used to prioritize traffic.

Indeed, seems like a pretty clear cut violation of rfc1925 points 5) and 12):

(5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

(12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.