3 ms·

What exactly is your complaint?

by alar44 5y ago

Karrot_Kream 5y ago
That middleboxes constantly stymie innovation through ossification. At least that's what I would think and I was going to post something very similar. At least we can just put overlay networks up and ignore most of the middleboxes out there.
- heyitsguay 5y ago
  As someone who doesn't have much background in networking, can you give some examples of what innovation could be possible without those middleboxes? I don't doubt you, just curious what you have in mind.
  - Karrot_Kream 5y ago
    I'm not sure why you're getting downvoted. There's nothing wrong with asking questions. Packets on the internet are transferred from host to host until they reach their destination. Your laptop on your local network is probably sending packets to your consumer router, which sends the packet to the ISP's router, and to other routers, until the packet reaches its destination. At each step of the way, routers can choose whether they wish to drop the packet or not. Due to various historically complicated reasons, many routers will drop packets they don't recognize. To give some examples, a small transit provider may have some really old routers that don't recognize modern versions of TLS, and these older routers usually did packet analysis on the hardware, so changes to the protocol need to be reflected in a hardware upgrade, which the transit provider will not do unless absolutely necessary for cost reasons. The provider may then choose to drop the packet because they don't recognize what kind of packet it is. Why should a middlebox care about what kind of packet is being sent? Many complicated reasons. CGNAT (Carrier-Grade NAT) is one of the iconic examples. Organizations do not want to learn IPv6, administer IPv6, or upgrade their hardware for IPv6, so they instead put layers of NAT in and block end-to-end connectivity on the internet. Another is that some netops will try to blanket drop packets that they don't recognize (think only allowing DNS queries to their specific DNS server, HTTP/TCP traffic, and maybe UDP traffic on a blessed VOIP port) to both defend from malicious users (instead of putting in the work to detect malicious traffic) and to better utilize the network they have and defer any network upgrades until absolutely necessary. Many middleboxes just drop non TCP/UDP traffic altogether, so protocols like SCTP which were designed for media streaming have a really hard time getting off the ground. It's complicated. Combinations of organizational culture, low margins, and lack of consumer understanding of their networks creates situations where middleboxes are aggressive without reason upon their traffic. This phenomenon is called protocol ossification, or just ossification in networking speak. https://en.wikipedia.org/wiki/Protocol_ossification https://en.wikipedia.org/wiki/Protocol_ossification
malwarebytess 5y ago
I thought he was pretty clear. The internet itself shouldn't be limited to merely TCP et al. It's just wires.
- batch12 5y ago
  It is more than just wires though. The traffic has to be routed- so it has to use some kind of protocol understood by every device in the path, right?
  - Ekaros 5y ago
    IP It really doesn't care what sort of wire it comes to router and what sort of wire it leaves over. And then not really even what is inside, it supports up to 252 different protocols inside. Now gathering and transferring information where to transfer is somewhat more tricky, but really IP is pair of addresses and some data.
    - deleted 5y ago
      [deleted]
    - ale42 5y ago
      Except that for many users IP is unusable, only the TCP and UDP layers are actually properly handled by most "home" device. SCTP? Maybe over UDP... definitely not as protocol 132 inside IP. And CGNAT makes things even more complicated.
  - jeroenhd 5y ago
    You're correct, of course, but that routing should strictly be done on the network layer. If some downstream router receives a packet for host 2002:abcd::abcd:ef that uses some unknown transport protocol, it should just forward the packet (unless a firewall rule explicitly bans the packet, of course). What we're seeing today is that routing hardware is also parsing the session transport layer (and sometimes even more!). TLS 1.3 lies about its TLS version (pretends to be a TLS 1.2 client hello) because some big companies can't deal with arbitrary version numbers. To "fix" this problem in the future, the real version numbers in the TLS protocol are now pretty much randomized to ensure no new middleboxes look at them again. Also take HTTP/2: most of the fixes HTTP/2 provides (basically forming a tunnel) are already embedded into smarter transport protocols like SCTP. Because of lack of middlebox support, using such an alternative transport wasn't even an option. Alternatives like SST also had no chance, leaving everything to the TCP-packets-within-TCP HTTP/2 approach because of compatibility. [1]: https://pdos.csail.mit.edu/archive/uia/sst/ https://pdos.csail.mit.edu/archive/uia/sst/

What exactly is your complaint?

by alar44 5y ago

What exactly is your complaint?

That middleboxes constantly stymie innovation through ossification. At least that's what I would think and I was going to post something very similar. At least we can just put overlay networks up and ignore most of the middleboxes out there.

heyitsguay 5y ago
As someone who doesn't have much background in networking, can you give some examples of what innovation could be possible without those middleboxes? I don't doubt you, just curious what you have in mind.
- Karrot_Kream 5y ago
  I'm not sure why you're getting downvoted. There's nothing wrong with asking questions. Packets on the internet are transferred from host to host until they reach their destination. Your laptop on your local network is probably sending packets to your consumer router, which sends the packet to the ISP's router, and to other routers, until the packet reaches its destination. At each step of the way, routers can choose whether they wish to drop the packet or not. Due to various historically complicated reasons, many routers will drop packets they don't recognize. To give some examples, a small transit provider may have some really old routers that don't recognize modern versions of TLS, and these older routers usually did packet analysis on the hardware, so changes to the protocol need to be reflected in a hardware upgrade, which the transit provider will not do unless absolutely necessary for cost reasons. The provider may then choose to drop the packet because they don't recognize what kind of packet it is. Why should a middlebox care about what kind of packet is being sent? Many complicated reasons. CGNAT (Carrier-Grade NAT) is one of the iconic examples. Organizations do not want to learn IPv6, administer IPv6, or upgrade their hardware for IPv6, so they instead put layers of NAT in and block end-to-end connectivity on the internet. Another is that some netops will try to blanket drop packets that they don't recognize (think only allowing DNS queries to their specific DNS server, HTTP/TCP traffic, and maybe UDP traffic on a blessed VOIP port) to both defend from malicious users (instead of putting in the work to detect malicious traffic) and to better utilize the network they have and defer any network upgrades until absolutely necessary. Many middleboxes just drop non TCP/UDP traffic altogether, so protocols like SCTP which were designed for media streaming have a really hard time getting off the ground. It's complicated. Combinations of organizational culture, low margins, and lack of consumer understanding of their networks creates situations where middleboxes are aggressive without reason upon their traffic. This phenomenon is called protocol ossification, or just ossification in networking speak. https://en.wikipedia.org/wiki/Protocol_ossification https://en.wikipedia.org/wiki/Protocol_ossification

malwarebytess 5y ago

I thought he was pretty clear. The internet itself shouldn't be limited to merely TCP et al. It's just wires.

batch12 5y ago
It is more than just wires though. The traffic has to be routed- so it has to use some kind of protocol understood by every device in the path, right?
- Ekaros 5y ago
  IP It really doesn't care what sort of wire it comes to router and what sort of wire it leaves over. And then not really even what is inside, it supports up to 252 different protocols inside. Now gathering and transferring information where to transfer is somewhat more tricky, but really IP is pair of addresses and some data.
  - deleted 5y ago
    [deleted]
  - ale42 5y ago
    Except that for many users IP is unusable, only the TCP and UDP layers are actually properly handled by most "home" device. SCTP? Maybe over UDP... definitely not as protocol 132 inside IP. And CGNAT makes things even more complicated.
- jeroenhd 5y ago
  You're correct, of course, but that routing should strictly be done on the network layer. If some downstream router receives a packet for host 2002:abcd::abcd:ef that uses some unknown transport protocol, it should just forward the packet (unless a firewall rule explicitly bans the packet, of course). What we're seeing today is that routing hardware is also parsing the session transport layer (and sometimes even more!). TLS 1.3 lies about its TLS version (pretends to be a TLS 1.2 client hello) because some big companies can't deal with arbitrary version numbers. To "fix" this problem in the future, the real version numbers in the TLS protocol are now pretty much randomized to ensure no new middleboxes look at them again. Also take HTTP/2: most of the fixes HTTP/2 provides (basically forming a tunnel) are already embedded into smarter transport protocols like SCTP. Because of lack of middlebox support, using such an alternative transport wasn't even an option. Alternatives like SST also had no chance, leaving everything to the TCP-packets-within-TCP HTTP/2 approach because of compatibility. [1]: https://pdos.csail.mit.edu/archive/uia/sst/ https://pdos.csail.mit.edu/archive/uia/sst/