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

The New Internet

tailscale.com

Post reply on HN
Print view View original

301–310 of 315 posts

Re: The New Internet

#301

Post by aboardRat4 »

alfons_foobar wrote: post #247
aboardRat4 wrote: post #225

Earlier quoted context omitted.

> https://blog.ipspace.net/2011/12/is-nat-security-feature/ >>Basic NAT (as defined in RFC 2663) performs just the IP address translation (one inside host to one IP address in the NAT pool). The moment the inside host starts a session through the NAT, it becomes fully exposed to the outside world. This is a lie. A "session through the NAT" does not really expose the host to the outside world, because in 99% of the ca…

> This is a lie. A "session through the NAT" does not really expose the host to the outside world, because in 99% of the cases this is a TCP session, and the NAT machine would drop all "out of order" packets. No, it's not. NAT only translates addresses and does not inspect the TCP "internals" (like sequence number etc, which would allow it to block certain packets). What you are describing is a stateful firewall that…

>No, it's not. NAT only translates addresses and does not inspect the TCP "internals" (like sequence number etc, which would allow it to block certain packets).

Yes it is. How would it forward response packets back if it doesn't track connections?

In real life I haven't seen "stateless NAT" for about 20 years.

But cgnat machines usually go beyond that and even verify sequence numbers.

Re: The New Internet

#302

Post by eqvinox »

aboardRat4 wrote: post #300
orangeboats wrote: post #292

Earlier quoted context omitted.

>what happens with an incoming packet if there are no firewall rules on the NAT gateway/middlebox? You get a Full Cone NAT. Once the middlebox maps an (internal IP, port) tuple to an external port, every connection to that external port would lead to that internal tuple. Why should Host C be able to reach Host A, when Host A is only speaking to Host B? I am sure you know this but still, I have to stress that NAT is m…

> If your router can handle NAT it certainly can handle an IPv6 firewall. The point is not that "it can", the point is that on ipv4 "it doesn't work without". In order for ipv4 to work at all you MUST use NAT, and implicitly a firewall, those two always work together even if there the person installing the system doesn't know the word "firewall", which is usually the case.

> The point is not that "it can", the point is that on ipv4 "it doesn't work without".

Hmm. I hadn't seen this brought up and I think it's a stronger argument than most others.

The IPv6 equivalent is services on ULA only, but that's not a default behaviour.

Re: The New Internet

#303

Post by otabdeveloper4 »

PLG88 wrote: post #297
otabdeveloper4 wrote: post #269

Earlier quoted context omitted.

The problem with TCP/IP is the lack of a standard and robust VPN/overlay network protocol. Everything we have is extremely fragmented and/or proprietary. IPv6 is completely useless and doesn't solve this problem. Normal people don't care if they have to pay 5 dollars instead of 50 cents to rent an IP address. This is a problem specific only to the huge providers, and we don't need to rollout a whole internet upgrade…

We are trying to change that with OpenZiti - https://openziti.io/ . Its an open source network overlay built with zero trust principles and deny by default in mind. We also built it for developers, so includes SDKs and other means to embed overlay networking directly into the SDLC.

It's a complex problem that hasn't even been formulated properly yet.

For example, every existing solution touts "security" and yet completely mangles the difference between authentication and encryption.

Authentication is important - you don't want random servers or users to enroll on your network, and you want good tools to rotate and manage secrets.

Encryption isn't important unless you care about state-level actors sniffing your traffic at the backbone. (And if you care about that then you already have your own datacenter.)

Meanwhile encrypting all network traffic is a huge performance penalty. (Orders of magnitude for some valid use cases.)

Re: The New Internet

#304

Post by [deleted] »

aboardRat4 wrote: post #300
orangeboats wrote: post #292

Earlier quoted context omitted.

>what happens with an incoming packet if there are no firewall rules on the NAT gateway/middlebox? You get a Full Cone NAT. Once the middlebox maps an (internal IP, port) tuple to an external port, every connection to that external port would lead to that internal tuple. Why should Host C be able to reach Host A, when Host A is only speaking to Host B? I am sure you know this but still, I have to stress that NAT is m…

> If your router can handle NAT it certainly can handle an IPv6 firewall. The point is not that "it can", the point is that on ipv4 "it doesn't work without". In order for ipv4 to work at all you MUST use NAT, and implicitly a firewall, those two always work together even if there the person installing the system doesn't know the word "firewall", which is usually the case.

[deleted]

Re: The New Internet

#306

Post by MerManMaid »

Borg3 wrote: post #294
MerManMaid wrote: post #291

Earlier quoted context omitted.

>What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. This is literally what they did, except they made it 128 bit rather than 64. The thing you're missing is that literally every IPv4 protocol breaks the second you change bit count. Before you change the 32-bit header you need to (a) redefine bit for bit every IP protocol so it can be understood by each IP capable device (…

I do NOT miss that point. The point is, new protocol should not be very different from previous one, unless its really necessary. After all those years and R&D put into IPv4 to make it better, we ended up with decent protocol. The only flaw is too small address space. With current IPv6, you have to throw up half of the stuff you know about IPv4 for, imo, no valid reason. And I will tell it again to be clear. Im not f…

>I do NOT miss that point. The point is, new protocol should not be very different from previous one, unless its really necessary.

>>The only flaw is too small address space.

>>>With current IPv6, you have to throw up half of the stuff you know about IPv4 for, imo, no valid reason.

ARP, DHCP, NAT, Lack of built in encryption are all huge problems that had to be addressed.

- ARP: incredibly inefficient, prime vector for abuse by malicious actors via arp poisoning

- DHCP: Man in the middle attacks, need I say more?

- NAT: Literally breaks the whole concept of IP addressing, incredibly inefficient as it requires manipulating packets mid-stream, literally designed as a temporary band aid to smooth our transition away from IPv4

- Built in encryption: You say this makes this more complicated but I believe it is the opposite, better security is built into the foundation rather than having to build it into every protocol on top of it. (ssh instead of telnet, SFTP instead of FTP, HTTPs instead of HTTP, ect) The issue I'm having with your argument is that you're saying that "you're fine with a replacement IP protocol which ditches the bad" and then go on to deride IPv6 for doing exactly what you're asking for. (keeping it as close to IPv4 as possible while ditching the biggest sources of technical debt)

>And I will tell it again to be clear. Im not fan of some IPv4+ contraption ideas like lets extend IPv4 address space and try to keep it IPv4. Thats DUMB.

But you literally did suggest exactly this when you said:

>What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done.

Did I somehow misinterpret this?

>Make new protocol, improve things that were bad in IPv4 (are they any?) and try to make it one way interop to IPv4 (IPv6 -> IPv4) and we are done.

IPv6 does provide a way to do exactly this, it's called NAT64 https://en.wikipedia.org/wiki/NAT64?useskin=vector

>Remember that you are building protocol for entire planet. It have to be relativly simple and easy to implement. Any extras should be layer up.

Again, this really makes me think you don't work in networking. When you abstract security from the underlining protocols you essentially leave a gaping hole in your security. The only surefire way to communicate securely is to bake encryption into the protocol itself. (and even then it is hit or miss)

This is why we moved from HTTPv2 to HTTPv3 This is why we stopped wrapping telnet into IPsec Tunnels and opted for SSH, this is why we stopped wrapping HTTPv2 in TLS tunnels and baked it into HTTPv3, and so on.

I don't want to spend a lot of time on IoT but as a network engineer I can say that they exist whether you like them or not and make up a large portion of traffic so we can't just not consider them when talking about how network protocols ought to be designed.

Re: The New Internet

#307

Post by Lammy »

jkrejcha wrote: post #254
wolfendin wrote: post #240

Earlier quoted context omitted.

Because the fields are there for humans, in the packet itself it’s a 32bit integer, and you can’t just arbitrarily make the src/dest fields in the packet bigger— it stops being IPv4 then.

I'm pretty sure the person you're replying to is saying that IPv6, should be IPv4 but longer, which is not at all an uncommon opinion, even if it's a breaking change to the IP protocol. And I'd argue there would've been incredibly strong benefits and much wider adoption if they did this. Sure, you'd still need new networking gear and software support to handle it, but the change is relatively simple (and potentially…

> The symbols that were chosen were also poorly thought out.

The wackiest example I've seen of this is the `ipv6-literal.net` notation for Windows UNC paths: https://devblogs.microsoft.com/oldnewthing/20100915-00/?p=12...

Re: The New Internet

#308

Post by catalypso »

ragall wrote: post #284
Esras wrote: post #273

Earlier quoted context omitted.

This feels like an overly-complex treatment of the Inverted Pyramid in journalism: https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism) , or Bottom Line; Up Front: https://en.wikipedia.org/wiki/BLUF_(communication) . Start with the important statements, then expand. Doesn't have to be the "Tell you what I'm telling you, tell you, tell you what I told you" format that many (American) students were taught, but s…

BLUF is bad, it's precisely a technique borne in the the world of newspaper publishing for writing catchy articles (what is now called clickbait). Classical philosophical writing is the exact opposite: start with some problems, elaborate in high detail and finish with a conclusion (the name says it all).

Clickbait is BLUF with a deceptive bottom line (BL). Clickbait is bad. You can choose to write in BLUF style without that.

In my experience, I only prefer "Classical philosophical writing" when I'm already convinced of reading the content (e.g. know the author, interested by the subject).

In almost all other cases, I prefer BLUF format: i.e. "get to the point, I'll read more if I'm intrigued".

Re: The New Internet

#309

Post by benreesman »

wmf wrote: post #229
mrmetanoia wrote: post #185

Earlier quoted context omitted.

Wouldn't the point be they're an indecent, possibly bad, actor by default since they're a business at all rather than just creating or contributing to protocols/standards to resolve the issues their product relies on to exist? The only way they could be a good actor is if they're using the money from their sales to fund that initiative with a plan to obsolete themselves. I suppose if you follow that thread though a l…

BTW the best way to make standards happen is to sell a product based on the standard. Academic standards don't go anywhere.

I have no idea what the adoption is, but this reminds me of the really nice work the buf.build people are doing with ConnectRPC.

I have a SaaS-crush on buf because they did such a good job on fixing such an annoying problem.

Re: The New Internet

#310

Post by Borg3 »

MerManMaid wrote: post #306
Borg3 wrote: post #294

Earlier quoted context omitted.

I do NOT miss that point. The point is, new protocol should not be very different from previous one, unless its really necessary. After all those years and R&D put into IPv4 to make it better, we ended up with decent protocol. The only flaw is too small address space. With current IPv6, you have to throw up half of the stuff you know about IPv4 for, imo, no valid reason. And I will tell it again to be clear. Im not f…

>I do NOT miss that point. The point is, new protocol should not be very different from previous one, unless its really necessary. >>The only flaw is too small address space. >>>With current IPv6, you have to throw up half of the stuff you know about IPv4 for, imo, no valid reason. ARP, DHCP, NAT, Lack of built in encryption are all huge problems that had to be addressed. - ARP: incredibly inefficient, prime vector f…

Yes, ARP had its problem, but they are solved right now. We have knobs in managed switches to handle it. ND just moved problems somewhere else, please read about ND table exhaustion and attacks.

DHCP snooping, need I say more? Also, if you are operating on network that is high security risk, you just layer VPN on top of it. Thats why they got invented in first place..

NAT is not that bad after all imo. I like its feature that my LAN is decoupled from WAN. Im multihomed and I do not need to bother annoucing prefixes to both ISPs.

Yes, you still misinterpret my statement. I mean: take IPv4 and just extend its address space and create new protocol out of it. It will not work with IPv4 itself because its not possible to do. But why take old IPv4 instead creating something from scratch? Simple, IPv4 works very well, why to trash last 30 years of R&D put to it? Sure, if you can came up with something better, go ahead. IPv6 did not deliver the promise.

Security is not that simple like, slap encryption everywhere and we are done, its more complicated matter. Encryption, control, management, endpoints security, router security. Whats the point of encryption of your device can be compromised due to shitty mgmt and traffic MITM again? Or whats the point of encryption if it can be cracked within hour doing MITM again due to protocol got old.

Yeah, HTTPv3.. created yet another problems that needs to be solved now. Why every time something new pops in, it trash past protocol R&D put to it, bringing same on similar problems AGAIN. Thats pathetic.

IoT, thats good example actually. It have E2E encryption (mostly its all HTTPS) and yet its p0wned so easly creating huge DDoS networks. Im starting to wonder if you have any security clue at all.

Post reply on HN