Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What would happen if we didn't use TCP or UDP?

github.com

Post reply on HN
Print view View original

91–100 of 116 posts

Re: What would happen if we didn't use TCP or UDP?

#91

Post by tsimionescu »

nickburns wrote: post #80
tsimionescu wrote: post #74

Earlier quoted context omitted.

DoT (DNS over TLS) would have been enough for privacy from your ISP, using a dedicated port. It's only when you want to protect from censorship that you need to hide the (encrypted) DNS traffic among other traffic that can't be easily blocked.

Security through obscurity is not the same as actual concealment. That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted. Many LAN operators conclude that the pragmatic impossiblility of blocking DoH is a net-negative for both network security and censorship avoidance.

> That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted.

Of course there is. Blocking all traffic with destination port 443 is virtually impossible. Conversely, blocking port 853 is trivial, and it forces all clients to either not resolve DNS, or downgrade to un-encrypted DNS.

Of course, if DoH had not been encrypted, it wouldn't have mattered that it uses port 443. But being encrypted yet easily identifiable would have also defeated half the point.

Re: What would happen if we didn't use TCP or UDP?

#92

Post by globular-toast »

immibis wrote: post #79
globular-toast wrote: post #3

What you want is a packet socket: sock_raw = socket(AF_PACKET , SOCK_RAW , htons(ETH_P_ALL)); IP networks should forward anything, but NAT is a major problem. Would be interesting to try with IPv6.

This gives you a raw Ethernet socket. For a raw IP socket, use AF_INET,SOCK_RAW,0. A raw Ethernet socket sends packets at the Ethernet level while a raw IP socket sends packets at the IP level. If you want to play on your local network you want Ethernet (maybe). If you want to send weird packets across the Internet you probably want IP, so that you don't have to waste effort doing route lookups and MAC address lookup…

Yeah, this was intended to eliminate the problems with protocol=0, but yeah you need to implement IP and maybe ARP to do a similar thing at this level. Thankfully IP is pretty simple to implement.

Re: What would happen if we didn't use TCP or UDP?

#93

Post by globular-toast »

paweladamczuk wrote: post #36

I always assumed any TCP/UDP packets would get captured by the OS network stack in order to be sent only to the processes listening on specific ports. I guess this is a security feature, since a process cannot even listen on some ports without having elevated privileges. I wouldn't expect another process being able to capture all this traffic anyway. This would also require a mechanism of sending the same stream to m…

It requires elevated privileges, but this is how programs like tcpdump and wireshark work. On Linux it's also possible to give a program these permissions for any user by setting "capabilities", specifically cap_net_admin and cap_net_raw.

Re: What would happen if we didn't use TCP or UDP?

#94

Post by kazen44 »

fancyfredbot wrote: post #58

It feels like the article ends with a cliffhanger! Why did a single packet of the custom protocol get through with all later packets dropped? Does anyone know?

my guess is the first packet got through a firewall, which created a flow.

subsequent packets then got blocked because the firewall has no way of matching this to an existing flow.

Re: What would happen if we didn't use TCP or UDP?

#95

Post by nickburns »

tsimionescu wrote: post #91
nickburns wrote: post #80

Earlier quoted context omitted.

Security through obscurity is not the same as actual concealment. That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted. Many LAN operators conclude that the pragmatic impossiblility of blocking DoH is a net-negative for both network security and censorship avoidance.

> That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted. Of course there is. Blocking all traffic with destination port 443 is virtually impossible. Conversely, blocking port 853 is trivial, and it forces all clients to either not resolve DNS, or downgrade to un-encrypted DNS. Of course, if DoH had n…

You've sidestepped my point and merely reiterated yours.

Both DoH and DoT achieve actual concealment (and therefore privacy and censorship avoidance) through encryption. That one is more obscure than the other doesn't change the fact that the whole point of both protocols is encrypted DNS queries, not obscured DNS queries.

And again, if I'm the network operator and a host can obscure/obfuscate its DNS queries, then I've lost some measure of control over my network and the hosts that connect to it. I can trivially redirect all TCP/853 traffic to my DoT-capable resolver of choice. I can't do the same for all TCP/443 traffic (i.e. redirect it to my DoH-capable resolver of choice).

I don't care that an eavesdropper can observe discrete TCP/853 traffic because it's encrypted. The whole point is maintained, and I've maintained control over my private network.

Re: What would happen if we didn't use TCP or UDP?

#96

Post by wahern »

Karrot_Kream wrote: post #10
noam_k wrote: post #6

Earlier quoted context omitted.

Is this a real issue? SCTP runs over IP, so unless your talking about firewalls and such, the support should be there. Edit: a quick search showed that NAT traversal is an issue (of course!)

Yes this is called protocol ossification [1] or ossification for short. Other transport layer protocol rollouts have been stymied by ossification such as MPTCP. QUIC specifically went with UDP to prevent ossification yet if you hang out in networking forums you'll still find netops who want to block QUIC if they can. [1]: https://en.m.wikipedia.org/wiki/Protocol_ossification

> Other transport layer protocol rollouts have been stymied by ossification such as MPTCP

AFAIU, Apple has flexed their muscle to improve MPTCP support on networks. I've never seen numbers, though, regarding success and usage rates. Google has published alot of data for QUIC. It would be nice to be able compare QUIC and MPTCP. (Maybe the data is out there?) I wouldn't presume MPTCP is less well supported by networks than QUIC. For one thing, it mostly looks like vanilla TCP to routers, including wrt NAT. And while I'd assume SCTP is definitely more problematic, it might not be as bad as we think, at least relative to QUIC and MPTCP.

I suspect the real thing holding back MPTCP is kernel support. QUIC is, for now, handled purely in user land, whereas MPTCP requires kernel support if you don't want to break application process security models (i.e. grant raw socket access). Mature MPTCP support in the Linux kernel has only been around for a few years, and I don't know if Windows even supports it, yet.

Re: What would happen if we didn't use TCP or UDP?

#97

Post by api »

labcomputer wrote: post #64
api wrote: post #55

Earlier quoted context omitted.

Let's say your ISP gives you a /64. Now you have to use V6 NAT... or assign a /96 internally. SLAAC won't let you do that. That, among other things, is a problem. SLAAC is too limited. You can use DHCPv6 but then you can't use Android because Android, and I think they're alone here, stubbornly and dogmatically refuses to implement it. I guess you could go around and statically assign V6 IPs to Android devices, or run…

Then your ISP isn’t following the RFCs. You might as well ask what you would do if you ISP gives your router a 17.0.0.0/8 address via DHCP. These are completely invented problems in your head. SLAAC can absolutely advertise a single /64 internally. It can advertise any /64 you tell it to. DHCPv6 can absolutely respond with DNS servers (and nothing else) in parallel. Configuring your SLAAC daemon to tell clients to ge…

> Then your ISP isn’t following the RFCs.

Oh, summer child...

Re: What would happen if we didn't use TCP or UDP?

#98

Post by smaudet »

Karrot_Kream wrote: post #81
crims0n wrote: post #28

Earlier quoted context omitted.

Because from an enterprise security perspective, it breaks a lot of tools. You can’t decrypt, IDS/IPS signatures don’t work, and you lose visibility to what is going on in your network.

Yes I know why netops want to block QUIC but that just shows the tension between the folks who want to build new functionality and the folks who are in charge of enterprise security. I get it, I've held SRE-like roles in the past myself. When you're in charge of security and maintenance, you have no positive incentive to allow innovation. New functionality gives you nothing. You never get called into a meeting and co…

Possibly even SRE shouldn't even exist, not only the structural issues you mention, but...

If you approach to security is that only square tiles are allowed because your security framework is a square grid, and points just break your security model, maybe it was never a valid thing to model in the first place.

I'm not saying security should not exist, but to use an analogy the approach should be entirely different - we have security guards, less so fences, not because fences don't provide some security, but because the agent can make the proper decision, and a lot of these enterprise models are more akin to fences with a doorman, not an professional with a piece and training...

Re: What would happen if we didn't use TCP or UDP?

#99

Post by kstrauser »

0x457 wrote: post #72
kstrauser wrote: post #66

Earlier quoted context omitted.

Android's right on this one (and I don't own an Android device that I know of, so this isn't me fanboying them). TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup.

Wait, what's not standard about /64?

RFC 3177[0] says:

"In particular, we recommend:

- Home network subscribers, connecting through on-demand or always-on connections should receive a /48.

- Small and large enterprises should receive a /48.

- Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's.

There was some walking that back in later RFCs, arguing that home customers could get by with just a /56.

[0] https://www.rfc-editor.org/rfc/rfc3177.txt

Re: What would happen if we didn't use TCP or UDP?

#100

Post by hylaride »

0x457 wrote: post #90
hylaride wrote: post #86

Earlier quoted context omitted.

Strictly speaking, it's perfectly standard and you can subdivide it (manually). However, for a variety of reasons subnetting smaller than a /64 is difficult and not supported at all via SLAAC (because the host portion is derived from the MAC which is already 48 bits, plus other overhead). So if you want to split up a /64 from your ISP, you're limited to manual configuration, DHCPv6 (and no android support), or other…

I understand that, but what I'm replying to says: "TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup."

RFC6177 specifically recommends a /48 to /56 because future security measures may require subnetting, even on home networks (eg having IoT devices on a secure DMZ).

Basically, giving out a /64 is the modern equivalent to ISPs saying "you have to pay extra to have more computers on the internet and you're not allowed to use NAT" that was actually a thing up until the mid 2000s.

The frustrating this is that there's no reason to do a /64 as IPv6 was literally designed to hand out huge IP ranges.

Post reply on HN