Comment by colmmacc
12 days ago
If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
[1] https://docs.github.com/en/enterprise-cloud@latest/organizat...
Having been messing around personally with getting my own blocks of IP addresses and routing[1] - I've become terrified at the idea of implementing access control based on IP address.
Unless your own organisation in the RR has the IP addresses assigned to you as Provider Independent resources, there just seems to be so many places where 'your' IP address could, albeit most likely accidentally, become not yours any more. And even then, just like domain names, stop renewing the registration and someone else will get them - I was that someone else recently...
[1] AS202858
Oh, cool! that's on my bucket list as well. I am still grappling with some concepts, though.
Do you have a writeup of your setup somewhere or can you recommend some learning materials ?
It's fun and has now become an addictive rabbit hole - trying to get packets from one location to the other in the fastest, most direct way (and at hobbyist budget level).
Initial writeup based on IPv6: https://abarber.com/Setting-Up-ASN-IPv6-Routing-BIRD-Teltoni...
Have been having fun recently with an IPv4 block and Asynchronous routing, working on writing that up right now :)
2 replies →
Anyone who relies on IP filtering for security deserves to have it broken. Change my mind.
I'll take that bait ;-)
IP filtering is a valuable factor for security. I know which IPs belong to my organisation and these can be a useful factor in allowing access.
I've written rules which say that access should only be allowed when the client has both password and MFA and comes from a known IP address. Why shouldn't I do that?
And there are systems which only support single-factor (password) authentication so I've configured IP filtering as a second factor. I'd love them to have more options but pragmatically this works.
Why are you (re-)implementing client security on provider end? If a client requires that only requests from a particular network are permitted... Peer in some way.
I do understand the value of blocking unwanted networks/addresses, but that's a bit different problem space.
Defense in depth is a thing but I agree that relying on it is not a good idea.
Defense in depth is not the point, zero trust networking is.
1 reply →
IP filtering + proper security is better than just having the security.
There's value in restricting access and reducing ones attack surface, if only to reduce noice in monitoring.
Actual curiosity, how would the new filtering be/is?
I've done a lot of IP filtering, it's what a lot of systems and services allow us to, so I'm curious what the IPv6 mechanism is
If you can't handle sites switching to ipv6 in 2015 (ten years ago) your security plan is garbage.
Thanks to the trend to SASE like Palo Alto GlobalProtect or ZScsler this practice is not a good idea anymore. Speaking of ZScaler, they are still IPv4 only, right?
> providers don't have an easy way to correlate addresses
Yes, they do. It's called DNSSEC.
Leaving aside that you applied the word "easy" to DNSSEC, how do you mean? How does DNSSEC solve the problem being discussed?
It was a somewhat flippant (given that GitHub doesn't implement DNSSEC either) dig at the idea of using hand-entered/hand-updated IP addresses for access control, rather than having the access control system look addresses up in the system designed to securely attest owner/ip mappings.
4 replies →