SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
SoylentNews
Address exhaustion is finally about to make us all take IPv6 seriously.
I know the theory; heck, I've even taught the theory in networking courses. What I would like to find - and haven't - is a source of practical information for introducing IPv6 into a network. How should the firewall be set up? What does Apache need, to make a website IPv6 accessible? What about HTTPS? SSH? DNS? What are the security gotchas? Hands-on, practical stuff.
I've looked around for online courses - I've even completed one. Unfortunately, the information was pathetic; I'm not sure I actually learned anything useful. There must be good sources out there. Any Soylentils have recommendations?
This discussion has been archived.
No new comments can be posted.
Ask Soylent: Good source for Practical IPv6 Training?
|
Log In/Create an Account
| Top
| 18 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
You can't cross a large chasm in two small jumps.
(Score: 1) by pTamok on Monday August 03 2015, @12:51PM
They used to state that IPV6 was designed for security from the ground up. No one says that anymore.
It may be old, but someone had designs on the design process and gutted the end-to-end security capablility/the hooks to make it easier to use encryption.
I wonder who that might have been?
But seriously, in the context of all the current brouhaha around security and intelligence services' ability to intercept communications, I would not be surprised if it turns out it was on their collective agendas to 'gut' the security capability of IPv6.
(Score: 3, Insightful) by VLM on Monday August 03 2015, @01:12PM
The history of ipsec in ipv6 mirrors the history of ipsec in general or in ipv4, in that I feel it was intentionally F-ed up and made into a hard to use mess of a technology which made ipsec useless in general. That has a side effect of making it completely uninteresting to the first two decades of ipv6 early adopters, but thats because ipsec with 40 bit des keys and all that BS is pretty much useless and a waste of time, in general, everywhere, not a conspiracy in ipv6 itself.
Maybe by analogy W2K used to be a popular OS in the early days of ipv6, but no conspiracy was necessary to ditch W2K by 2015.
There could be conspiratorial aspects of "here's a shitty VPN technology, the worst out there, so lets product tie it deeply into ipv6 as "the" security technology for ipv6, such that when the hivemind trashes IPSec in general, ipv6 will have no security theater at all, and better yet will not have a generic universal crypto layer that might have actually worked."
I'm not sure encrypting the line really gives you anything now a days anyway. You can assume the endpoints are both owned by .com and .gov and .cn and .ru and probably others, so decrypting data off the line is a total waste of computational effort. Maybe not writing endpoint code full of exploits would have saved more traffic than inserting weak security theater. Meanwhile if you're actually doing something important you'd need a secure well written VPN system anyway instead of some PoS totally powned OS layer, or you implement it at the app level like websites over SSL aka https. I'm not convinced it belongs in the feature list at that layer, and the marketplace in general seems to agree.
Putting ipsec in ipv6 20 years ago was just an architectural mistake. It doesn't belong at OSI layer 3 in OS driver code.
(Score: 2, Interesting) by pTamok on Monday August 03 2015, @01:33PM
The implementation may have been flawed, but I'm not convinced it is an architectural mistake to try and 'bake-in' security. It depends on what you are baking in, and how flexible it is e.g. with the ability to change to new encryption algorithms.
I come from the school of 'the network should be dumb and the end-points intelligent', but I have considerably modified my position in the face of reality and realise it is a bit more complicated than that. Link-based encryption is only really as good as the management of the keys, but in general having something that discourages casual interception is not a bad idea. After all, we have gone from open WiFi to WEP to WPA: if encryption were purely an end-system requirement, none of that would have developed.
(Score: 3, Interesting) by VLM on Monday August 03 2015, @04:11PM
After all, we have gone from open WiFi to WEP to WPA: if encryption were purely an end-system requirement, none of that would have developed.
That's primarily to stop people from freeloading on my wifi, using up my transfer cap, illegal downloads.
If there were a simpler way to keep people off my wifi, then the complicated crypto stuff wouldn't get used.