The original address: www.techguruhub.net/2021/05/iso…
The original author: www.techguruhub.net/author/tech…
Published: May 13, 2021
The so-called “stack” protocol model is one of the most basic techniques in network architecture. The model was created in the late 1970s as part of a larger attempt to create general network principles and methods. The Basic Reference Model for Open Systems Interconnection, also known as the Open Systems Interconnection Reference Model or “OSI Model “, was developed in 1983 by CCITT and ISO in conjunction with their efforts. This architecture provides a seven-level abstract network model that describes the standard behavior of the entire network and its components.
ISO OSI reference model
In this model, functionality is divided into two parts.
The media layer handles binary data encoding through physical communication media, the data connection layer identifies data frames used by two interconnected “nodes”, and the network layer handles multi-node networks, including managing the addressing and routing behavior of data transfers between additional hosts.
The server layer is concerned with the role of the terminal host. Data segmentation into packets, end-to-end traffic management, packet error recovery, and multiplexing are all performed by the transport layer. The session layer, the presentation layer, and the application itself are layers above the transport layer in the OSI model.
The internal nodes only use the network layer to make forwarding decisions for each packet, which is managed in the network model as a series of internal nodes and a set of connected hosts, while the hosts use the transport layer to control the data flow between the interacting hosts.
This model implies a clear distinction between the roles of nodes and hosts, as well as the data they need to perform their functions. Nodes do not need to know transport layer Settings, and hosts do not need to know network layer Settings (Figure 2).
Figure 2: Host and node functions
Network layer functions are encoded as IP headers for packets in the Internet Protocol Suite, while transport layer functions are encoded as transport headers, usually TCP or UDP headers (although other headers are also defined by IP). According to the Internet architecture model, a packet should be able to travel over the Internet regardless of the transport header added to it.
Therefore, the importance of your input in the IP negotiation area of the IP packet header should not matter at all. It has little to do with the web! .
Note that the extension header field in IPv6 is exactly the same. However, for whatever reason, IPv6 scrambles the eggs, and some extension headers, such as hop-by-hop and Routing extension headers, are for network components. On the other hand, most of the extension headers seem to be targeted at the target host. If extension headers are specified only as extensions to the host (or destination), then the IPv6 network should ignore them, and if they are for network selection, the host should ignore them. Perhaps this is one of the differences between philosophy and reality.
Strictly speaking, the agreement area in an IPv4 header cannot be included in the first place. In principle, the network does not care about the transport protocol used by the transport host. This also ensures that if two transport hosts want to hide transport protocol control Settings from the network, the network may not be affected at all.
In today’s public Internet, transport protocol headers are still very important to network availability. In fact, not only must the transport protocol be accessible to the network, but the transport protocol the host wants is also important to the network. This is because many components of today’s networks don’t just look at the transport headers of the packets they transmit, but depend on the details contained in the transport headers. Network address converters, equivalent multipath load balancers, and quality-of-service policy engines are examples of such dependencies. In order to make unambiguous judgments about the processing of all packets in a single transport stream, these networking features make assumptions about the visibility of transport headers in IP packets. Often, these networking capabilities go a step further, processing only packets with well-known transport headers (typically TCP and UDP) and ignoring everything else. This is also going too far, as the rule of thumb today is that an unbroken IP packet with a TCP transport header, one end of which uses port 443, and an unbroken IP packet with a UDP transport header, one end of which uses port 53, have a higher probability of bringing its data payload to its intended destination. Any attempt to extend this extremely limited range of packet characteristics runs the risk of breaking network-based connections.
Encrypted transport header
If using new transport protocols over the public Internet is a self-limiting act, why are we still exploring the possibility of encrypting transport protocols so that all transport headers are hidden from the network?
“Edward Snowden” is a possibility. In addition to these findings about widespread surveillance [RFC 7624], the Internet Engineering Task Force (IETF) took the “analogy” approach and concluded that “widespread surveillance is an attack” [RFC 7258]. The common solution to such spoofed attacks is to increase the amount of protection for Internet traffic to make network-based monitoring more difficult. This IETF answer includes not only using TLS to encrypt session payloads over the Internet whenever possible and changing device behavior profiles to make it the default operation, but also other areas of Internet communication where breach of trust models is considered a problem.
The behavior of the DNS protocol, as well as the transport of protocol headers, are incorporated into this IETF general obfuscation work. We’ve come a long way from the days when hosts couldn’t perform encryption. Strong encryption is no longer a luxury option that limits use, but a minimum requirement that any consumer can now fairly plan to use. If the goal is to limit knowledge leakage in all aspects of Internet communication systems, controlling metadata is as critical as the data itself. Using anonymity in the transport header field will help protect user privacy and prevent such attacks or packet abuse by network devices [RFC 8404].
I think, however, that privacy concerns are only part of the story. While masking host functionality from the network is the direction that some parts of the Internet ecosystem are actively following through transport head encryption today, it may not be at the heart of these efforts to encrypt Internet traffic, and it plays into a common fear of security states operating in relatively non-standard ways.
It’s not clear what the goal is here, and as with many interdependent complex structures, deliberately masking one part of the mechanism from another can have both advantages and disadvantages. RFC 8546, entitled “A Diagram of Network Protocols”, was recently published by the IAB (April 2019). According to today’s RFC guide, it is a short text (9 pages), but brevity does not always mean transparency. The paper seems to have buried whatever it was trying to say in a thick layer of vague terminology so that it fails to say anything useful. The IAB document seems to have been prompted by a lengthy debate in the QUIC Working Group about the use of visible spin in the QUIC Transport protocol (see previous article on this subject), I suspect it started out as an argument for the visibility of a certain traffic behavior into the network, but the IAB’s prediction of the problem ended up offering little solution. The IAB is not known as a prolific critic, but any question that prompts the IAB to answer, no matter how arcane, is a sign that the subject is universal, rather than a rather esoteric squabble buried deep in a particular programming.
Since encrypted transport headers are a transport problem, it is natural to wonder if the IETF transport area can do a better job than the IAB of explaining the problem simply and in detail. The Transport Area Working Group of the Internet Engineering Task Force has completed an analysis of this issue, and the Internet draft “Considerations on Transport Header Confidentiality, Network operation, and evolution of Internet Transport Protocols” has now entered the RFC edit queue.
“According to the document,” this article discusses the potential impact when network traffic uses protocols with encrypted transport headers. It raises questions to think about when developing new transport protocols or features.
This paper appears to be an attempt to include a more realistic commentary on header encryption than previous IAB efforts.
Obviously, at 49 words, this extended review won’t be a quick read, but will it improve the consistency of the discussion points?
The document begins by offering several reasons for the use of header content on the Web. In this case, they cite the condition of link aggregation and the problem of packet reordering. To get a more detailed picture of traffic than can be obtained from the source and destination IP address pairs, the network can often peer down into the transport head. For the name of IPv6 traffic, it is an IPv4 proxy. (It’s hard to see what IPv6 traffic tag fields are for anyway, despite the confusion about their intended functionality!) Under the guise of “operational quality”, the document refers to differentiated service attempts aimed at causing selective traffic disruption (this “quality” label has always seemed to me to have an Orwellian connotation; a more honest label would have been “selective service degradation” or even just “carrier station service”). The document also lists the different types of network analysis that network operators can do with transport-level data, such as traffic profile analysis, latency and jitter, and packet loss. On the other hand, the document strikes me as offering a dubious collection of reasons. It reminds me of a voice phone operator defending its phone hacking, claiming that the intelligence gathered, or in other words, the details of what people do to each other over the phone, might be used to improve the phone network. The document also cites a vague definition of “availability,” arguing that if network operators were no longer allowed to eavesdrop on the transmission parameters of active conversations, their ability to operate stable networks would be compromised in some unspecified way.
Obviously, none of the arguments presented here stand up to close examination.
In its censorship, it often leans towards a privacy-oriented approach. The privacy argument, on the other hand, seems only to provide an implicit justification for a larger conflict of opinion between materials and transportation. To a large extent, from an application perspective, the problem is that network operators try to “comb” the traffic by modifying the transmission headers, resulting in nothing more than an injury to the application data flow and a decrease in network transmission efficiency. This is where we find the real problem between the network and the host in today’s Internet: the selective reduction of transmission efficiency using the network in the name of network service consistency.
Interference transport protocol
First, we should consider the conflict between hosts and networks on the Internet.
In the world of telephony, network providers are responsible for all traffic. You can keep a virtual circuit capable of real-time voice conversation, or a fixed-capacity channel between two endpoints of the network. If you choose one of these platforms, you can’t go faster than the contract says, because if you go slow, you can’t free up popular capacity for others to use. Clearly, networks pay a premium for higher capacity leases. This situation has largely improved with the introduction of packet networks. Because there is little compliance on the network, different applications (or traffic) compete for the same communication capacity. There are challenges for networks that want to manage generic communication services that are assigned to each other by customers.
This was the driving force behind much research on “quality of service” (or QoS) on the Internet in the 1990s and 2000s. Network providers decide to offer “better standards” for certain customers and traffic profiles (no doubt for a fee). However, if a network has a fixed size, giving some customers more network capital necessarily means giving others less capital. While the network can interrupt a conversation in a variety of ways to make it move more slowly, it is more difficult (and perhaps even harder in some cases) to make a communication conversation move faster. This means that if you give special consideration to one traffic flow, you may cause all other traffic flows to move more slowly in order to free up some network bandwidth for those sessions that should be prioritized to extend their sending window and fill this newly freed space. The so-called “performance enhancing proxy” does not really make the selected TCP session move faster. Even so, they are able to slow down other TCP sessions, freeing up some bandwidth for the selected session to provide a lower probability of packet failure and thus have better data throughput limits. Discarding packets is a method of moderating sessions. Changing TCP control parameters is a more subtle but no less powerful process. If the supplied TCP window size parameter is reduced, the sender can easily throttle its sending rate.
Clearly, applications do not see the network’s selective throttling of active TCP sessions as a sympathetic gesture, and there have been two large responses in terms of device size. First, a new congestion management algorithm has been implemented that is less susceptible to packet loss and more sensitive to improvements in end-to-end bandwidth delay products for routing across networks. This is the BBR TCP control protocol, which is a modern sender control algorithm for TCP. However, BBR is also susceptible to TCP window size abuse on paths. Encrypted transport headers are an important goal in protecting sessions from such network intrusions. This is the second answer, which confuses the location of TCP control details in packets.
As mentioned earlier, you can’t remove transparent transport headers from IP packets over the public Internet, and even encrypting TCP headers would almost certainly result in the same network giving up the answer. However, the host can choose to ignore these transport header options. Although the visible transport header cannot be deleted, it can be rendered useless by the host.
A “fake” external TCP wrapper could be used as cannon fodder for networks that want to peek into the traffic and exploit session Settings while overwriting the actual TCP access header in an encrypted payload. Other than the observation that the TCP terminal host does not respond to the abuse of its window parameters, there are no visible network characteristics to indicate that this is happening.
The trouble with this approach, however, is that today’s programs try to gain control not only of the transmission session parameters from the intervening network, but also of the server on which the application resides. In theory, a program can use the “raw IP” interface to access the platform’s I/O programs, but in reality this is almost impossible on implemented systems. Platforms used in manufacturing have a tendency to be skeptical of applications. Given the prevalence of ransomware, this level of paranoia online is probably justified). Disabling the platform to handle all aspects of the transport protocol and transferring ownership of the transport protocol from the kernel to device space is a daunting task.
Therefore, it makes sense to adopt the POLICY of QUIC, where the SHIm wrapper uses UDP as the visible transport header and drives the TCP header into the encrypted payload of the IP packet. In this case, UDP is similar to best because it has no transport control and only uses local port numbers. Because it is a UDP session that uses TLS in so many ways, QUIC appears on the network to be a UDP session that uses TLS sass-like encryption. End-to-end TCP traffic control is now true end-to-end traffic, since only two applications at the “ends” of the QUIC transport will see the end-to-end transport control parameters encoded in the end-to-end encrypted UDP payload. The host platform has minimal control over UDP packets, and then the scheme is given full control over session transport activities.
Transport and Content
Perhaps the shift to opaque transport headers reflects more than the need for more secure autonomy for applications. The changes to QUIC could be seen as service providers’ revenge for another round of the old, very familiar game, in which network operators levy fees on content providers by hijacking traffic — or, as it has been called, a tussle over “net neutrality”.
Several times, network providers have introduced policies to throttle traffic types that they say are “unfairly” using their networks in any way. The vagueness of all this is more likely due to the carriers’ basic intent to extort shipping fees from content publishers in a simple form of extortion.” My network, my code. You, the client, are the one paying!”
I think a lot of the carriers in this market think they are victims because they let the content providers take all the profits.
To recapture any revenue streams they have lost, they are seeking to recapture their “equal share” of revenue by pressuring the giants of the content industry to reimburse them for a fair share of transmission costs. If, on the other hand, extortion pressure is enforced by manipulating the transport control parameters of traffic passing through the transport network (or, in other words, hijacking traffic), then the obvious response is to encrypt the transport control along with the content to prevent some immediate traffic profile manipulation. And that may be a more compelling argument for why QUIC is so relevant.
If the conflict between delivery and services is a race for primacy, it seems that those on the content side are winning. By encrypting at any level of the host portion of the protocol stack, even at the transport layer, content vendors enable carriers to selectively discriminate and pit content vendors against each other, thereby refusing to provide information to the carriers. If the network’s capabilities were limited to a fully encrypted UDP packet stream, one data stream might look identical to another, and selective discrimination would be impossible. If that’s not enough, padding and deliberate packet differences will obscure any attempt at traffic analysis.
However, when I say “things”, I really mean “software”, and when I say “applications”, I really mean “browsers”, because WHAT I’m really talking about is the Chrome browser, and the Chrome browser, I mean Google.
The huge dominance of mobile traffic in the market, and the huge dominance of Android in mobile devices, has had a big impact on the sector. Given Google’s inherent advantage over all mobile devices, and the majority of browser platforms in the room, it’s hard to see how the company can lose this battle. However, if Google defeats the wagon companies in this battle, it is doubtful that this will be the end of the store. It is highly likely that the carriage industry will follow the traditional print media and go to politicians, arguing that Google has damaged the business model that provides the nation’s communications infrastructure, harming the national interest, and that political intervention is needed to restore some balance to the market and make the carriage market a viable option. In other words, since Google has effectively lost the remaining value-containing carrier business, it can now compensate carrier operators to restore its profitability.
The technical aspects of encryption and data breaches, as well as concerns about the viability of different business models across all industries, went out the door at this point, replaced by a host of lawyers and politicians. As we move through the myriad vague attempts by participants to leave the national market, we can focus on the real issues.” What is a sustainable business collaboration between transport and content?”
In such a politically charged environment, the choice is either for different business actors to negotiate and find a deal they can all live with, or for policymakers to craft an outcome that is almost certain to leave everyone unhappy.
Whatever the outcome, it should be interesting to see how this plays out over the next few years. Remember to bring popcorn.
www.deepl.com translation