Hacker News new | ask | show | jobs
by giovannicarruba 3005 days ago
IMO the article completely fails to describe the actual issue.

- "Then there is the NAT function, where the 5-tuple of protocol, source and destination addresses and the source and destination port numbers is used as a lookup vector into a translation table, and both the IP and the inner transport packet headers are altered by the NAT before passing the packet onward."

Nice try, but if the outer layer is UDP, then NAT alters the UDP packet headers. The QUIC payload is never touched.

- "Many network operators use the IP and transport packet headers to perform traffic engineering functions, packet interception and forced proxy caching. Various forms of middleware may reach into the TCP control fields and manipulate these values to modify session flow rates. All of these activities are commonplace, and some network operators see this as an essential part of their service."

I don't see why the people tasked with standardizing Internet protocols now have to make provisions for the jerks who literally break the Internet.

- "This bit, the “spin bit” is intended to be used by passive observers on the network path to expose the round trip time of the connection. The management of the bit’s value is simple: the server simply echoes the last seen value of the bit in all packets sent in this connection. The client echoes the complement of the last seen bit when sending packets to the server. The result is that when there is a continuous sequence of packets in each direction this spin bit is flipped between 0 and 1 in time intervals of one Round Trip Time (RTT). Not only is this RTT time signature visible at each end, but it is visible to any on-path observer as well."

I have literally no idea why a protocol should actively leak unnecessary information to a passive observer, and I have no idea what passive observers would do with the information they can deduce from this "spin bit". The payload is still encrypted, so you still can't do all the "traffic engineering, packet interception and forced proxy caching". As a passive observer you sit somewhere in the middle of the whole stream, and if you can even fish out the necessary packets (they might take different routes in each direction), you still don't know how far you are from the other end. Not even talking about the random processing delays at the server end. You're measuring garbage. How is this bit even useful for anything?

3 comments

It seems you were the one who completely failed to understand the article. Your first point implies you think the author was talking about QUIC in that section, when instead the author was merely using NAT as an example of packet inspection to provide context to the topic. Your second point is in fact exactly the point of the entire article, which itself is a commentary on the decision making process and factors in that process that IETF is presently using to decide exactly how much to "break" the protocols, and moreover on the observation that many people in the IETF do not consider this to be "breaking" at all. Your third point is a commentary on the utility of the bit itself, which is not really the focus of the article anyway.

You claim: "IMO the article completely fails to describe the actual issue."

How so?

> Nice try, but if the outer layer is UDP, then NAT alters the UDP packet headers. The QUIC payload is never touched.

You didn't understand the article. It's talking about existing TCP traffic here, not QUIC.

> I don't see why the people tasked with standardizing Internet protocols now have to make provisions for the jerks who literally break the Internet.

1) A lot of them are the same people and 2) internet protocols are worthless without adoption, which is why we're still groping towards IPv6.

Or for a shorter answer: Politics.

> How is this bit even useful for anything?

Here's an internet draft proposing adding a spin bit which discussed, among other things, some uses for it: https://tools.ietf.org/html/draft-trammell-quic-spin-01

The point is that QUIC is supposed to be fully encrypted below the UDP layer. The question is why add bits in the clear on top of this to water it down and open an avenue for potential abuse.
Yes but it doesn't really say why anyone wants this spin bit. What are they going to do with it? Measure RTTs? Why? What for?
The currently top-voted comment in this thread explains it: https://news.ycombinator.com/item?id=16696159
Yes questioning the spin bit is the point of the article.