Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 12/03/2013 04:02, Michael Mol wrote: We should be pounding away on the fact that we're running out of IP addresses... period... end of story. If people ask about NAT, then mention that the undersupply will be so bad that even NAT won't help. In my presentations, I've stopped bothering to wait for people to ask about NAT, because it starts off in their minds from nearly the beginning--and until they get that question answered, most of what I say washes past them as ancillary and not as important as the question pressing on their minds. In one short paragraph you said exactly what I was trying to say in 4 mails (and still didn't succeed) -- Alan McKinnon alan.mckin...@gmail.com
Re: [Bulk] Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On Tue, 12 Mar 2013 13:29:38 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: We should be pounding away on the fact that we're running out of IP addresses... period... end of story. If people ask about NAT, then mention that the undersupply will be so bad that even NAT won't help. In my presentations, I've stopped bothering to wait for people to ask about NAT, because it starts off in their minds from nearly the beginning--and until they get that question answered, most of what I say washes past them as ancillary and not as important as the question pressing on their minds. In one short paragraph you said exactly what I was trying to say in 4 mails (and still didn't succeed) You know I agree except the only people that brought NAT up and got fixated on it were those that were advocating ipv6!?!?
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 11/03/2013 06:00, Walter Dnes wrote: On Sun, Mar 10, 2013 at 05:07:25PM -0400, Michael Mol wrote NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. The best real reason for moving to IPV6 is address space (or lack thereof, in the case of IPV4). The people who are truly interested in speeding up IPV6 adoption should do their best to shut up the internet hippies who constantly rant and rave about how NAT is evil. Don't let the cause get distracted by that unrelated issue. Focus on the core issue. You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. -- Alan McKinnon alan.mckin...@gmail.com
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On Mon, Mar 11, 2013 at 10:22:39AM +0200, Alan McKinnon wrote You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Agreed. But we shouldn't be pointing out that NAT has partially solved the problem, and giving people false hope that NAT will solve the shortage problem forever. We should be pounding away on the fact that we're running out of IP addresses... period... end of story. If people ask about NAT, then mention that the undersupply will be so bad that even NAT won't help. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. That's why I wwant to avoid that propaganda battle. It's been lost already. Deal with it. Don't waste time and effort on it. Put your effort into pounding away on a simple issue that people do understand... we're running out of IP addresses. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. I disagree with you there. IPV6 adoption will be driven by shortage of addresses, which people can understand. It will not be accomplished by sermons about the evils of NAT whilst people's eyes glaze over. A preachment, dear friends, you are about to receive, is on John Barleycorn, Nicotine, and the Temptations of NAT. And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT being available, rather than no IPV6. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
Don't waste time and effort on it. Put your effort into pounding away on a simple issue that people do understand... we're running out of IP addresses. We have run out of unallocated ones, there are still loads of unused ones and even more due to global NAT, and even some being released. It is true eventually it will be an absolute problem but hopefully by then we will have a cleaner ipv7. Lets hope ISPs get smarter as recently they have gone downhill with all their *DANGEROUS* as cited by snort.org and compulsory layer 7 sifting. Until ipv6 is revised I can't see a day when there will be no ipv4. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/09/2013 07:53 AM, Kevin Chadwick wrote: There is no reason to believe that IPv6 will result in an increased use of IPsec. Bull. The biggest barrier to IPsec use has been NAT! If an intermediate router has to rewrite the packet to change the apparent source and/or destination addresses, then the cryptographic signature will show it, and the packet will be correctly identified as having been tampered with! http://marc.info/?l=openbsd-miscm=135325641430178w=2 It's hardly difficult to get around that now is it. Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was designed from the beginning to allow you to do things like sign your IP header and encrypt everything else (meaning your UDP, TCP, SCTP or what have you). Setting up a tunnel just so your IP header can be signed wastes another 40 bytes for every non-fragmented packet. Ask someone trying to use data in a cellular context how valuable that 40 bytes can be. You are wrong the biggest barrier is that it is not desirable to do this as there are many reasons for firewalls to inspect incoming packets. I don't agree with things like central virus scanning especially by damn ISPs using crappy Huawei hardware, deep inspection traffic shaping rather than pure bandwidth usage tracking or active IDS myself but I do agree with scrubbing packets. It's not the transit network's job to scrub packets. Do your scrubbing at the VPN endpoint, where the IPSec packets are unwrapped. Trusting the transit network to scrub packets is antithetical to the idea of using security measures to avoid MITM and traffic sniffing attacks in the first place! I never said it was. I was more thinking of IPSEC relaying which would be analogous to a VPN end point but without losing the end-end, neither are desirable, NAT has little to do with the lack of IPSEC deployment. What do you gain considering the increased resources, pointlessly increasing chances of cryptanalysis and pointlessly increasing the chances of exploitation due to the fact that the more complex IPSEC itself can have bugs like Openssl does, not to mention amplifying DDOS without the attacker doing anything, which is the biggest and more of a threat than ever, or are you going to stop using the internet. When ipv4 can utilise encryption without limitations including IPSEC but more appropriately like ssh just fine when needed you see it is simply not desirable and a panacea that will not happen. You are simply in a bubble as the IETF were. With IPsec, NAT is unnecessary. (You can still use it if you need it...but please try to avoid it!) Actually it is no problem at all and is far better than some of the rubbish ipv6 encourages client apps to do. (See the links I sent in the other mail) Please read the links before you send them, and make specific references to the content you want people to look at. I've read and responded to the links you've offered (which were links to archived messages on mailing lists, and the messages were opinion pieces with little (if any) technical material.) Re DNS support for IPv6 Increased size of DNS responses due to larger addresses might be exploited for DDos attacks That's not even significant. Have you looked at the size of DNS responses? The increased size of the address pales in comparison to the amount of other data already stuffed into the packet. It's been ages since I looked at that link and longer addresses would certainly be needed anyway but certainly with DNSSEC again concocted by costly unthoughtful and unengaging groups who chose to ignore DJB and enable amplification attacks. What from DJB did they ignore? I honestly don't know what you're talking about. They completely ignored dnscurve.org or that RSA768 was not strong enough to be a good choice and ECDSA should be looked at and most importantly the DOS amplification (we are talking years ago). I even had a discussion with a dns caching tools (that I do like a lot) author who completely dismissed the potential of RSA being broken for years and years. Guess what's come to light since. His latest on the DNS security mess http://cr.yp.to/talks/2013.02.07/slides.pdf I've never before in my life seen someone animate slideshow transitions and save off intermediate frames as individual PDF pages. That was painful. Yeah, xpdf worked well though. I actually couldn't find the link and looked it up and thought it was just an update of 2012 as it had the same title and only got around to reading it about an hour later. So, I read what was discussed there. First, he describes failings of HTTPSEC. I don't have any problem with what he's talking about there, honestly; it makes a reasonable amount of sense, considering intermediate caching servers aren't very common for HTTP traffic, and HTTPS traffic makes intermediate caching impossible. (unless
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
No, there was simply no useful result that came up. Incidentally, both links you provide *did* come up...but I dismissed them because I couldn't imagine anyone using them as a reference except in trying to deride Henning Brauer. http://marc.info/?l=openbsd-miscm=129666298029771w=2 He goes from advocating NAT444 to a spew of pejoratives about something. NAT444 is one of the nastiest, user-disempowering things to hit the Internet to date. The rest of this email is him bitching about having to parse CIDR notation. How disengenuous. He certainly doesn't. Did you miss the sarcasm. The only reason he advocates is because others using it allow him to keep running ipv4 pure networks. After that I'm sure you can forgive me if I note him to have absolutely no reason to be biased and give him a bit more credit and take his experience of writing one of the best and widely used interrupt driven firewalls and so code to deal with ipv6, helping get the netqmail patch sorted and runs his own decent sized network over yours who I am sure is genuine but could well be partial to ipv6 because as you say you teach setting up ipv6 networks. http://marc.info/?l=openbsd-miscm=124536321827774w=2 http://marc.info/?l=openbsd-miscm=135325826302392w=2 This email has absolutely no technical content whatsoever. Did you not follow the threads? I couldn't find the juicier threads about client troubles due to added complexity but here's some relevent ones and many by very competent devs. (and if I'm honest who tend to shadow every other list I've come across so far as long as you are not timid and can take a hit, though Gentoo is up there). http://marc.info/?l=openbsd-miscm=128822984018595w=2 http://marc.info/?l=openbsd-miscm=135325736302228w=2 http://marc.info/?l=openbsd-miscm=128825496411711w=2 http://marc.info/?l=openbsd-miscm=129665675320651w=2 http://marc.info/?l=openbsd-miscm=135111069427240w=2 http://marc.info/?l=openbsd-miscm=135110983026959w=2 http://marc.info/?l=openbsd-miscm=135110833526455w=2 http://marc.info/?l=openbsd-miscm=135110805826344w=2 http://marc.info/?l=openbsd-miscm=135110703125929w=2 http://marc.info/?l=openbsd-miscm=135110533625263w=2 http://marc.info/?l=openbsd-miscm=124537193506202w=2 -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. The best real reason for moving to IPV6 is address space (or lack thereof, in the case of IPV4). The people who are truly interested in speeding up IPV6 adoption should do their best to shut up the internet hippies who constantly rant and rave about how NAT is evil. Don't let the cause get distracted by that unrelated issue. Focus on the core issue. I completely agree divide and conquer tactics. You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. NAT was around way earlier and may I state again also that I have externally facing servers and games machines behind NAT. So are you saying that you think it is good for every machine to be in a DMZ, few chosen ones yes. I disagree completely as I do with the usefullness of push-email. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. NAT has more uses than those two, NAT type of functionality is apparently desired by some ipv6 networks to allow easier ISP migration. It's true NAT distracts from the bad points of ipv6 and which is the only part irrelevent for ipv4 modded to work with a larger address space (ipv5). I wonder if this is an example of how these technologies can get so convoluted? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 12/03/2013 00:45, Walter Dnes wrote: NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. I disagree with you there. IPV6 adoption will be driven by shortage of addresses, which people can understand. It will not be accomplished by sermons about the evils of NAT whilst people's eyes glaze over. A preachment, dear friends, you are about to receive, is on John Barleycorn, Nicotine, and the Temptations of NAT. And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT being available, rather than no IPV6. Hmmm, I'm still not convinced. NAT (plus a whole boat load of other crap we've accumulated over the years, NAT merely being the well-known poster-boy) is so ingrained in people's heads it is now one of those things that we have to deal with. Ignoring it (and the other crap too) is not going to change that it really is up at the top of people's thought process. When I say people I of course mean people I interact with. I don't claim to speak for all persons who deal with the internet somehow. Yes, we should and must pound away that IPv4 is a limited resource and it's close to being used up. But we still have to deal with the other objections that rightly or wrongly get dumped on the table too. Why do I think we must deal with these other issues rather than concentrate on the major one? Because the other guy won't let it go and won't really engage a discussion about IPv6 for real as he's sitting with all these other objections uppermost in his mind. Chief amongst them is the knowledge that he will have to redesign his entire network from scratch (we all know that IPv6 is not a drop-in replacement for IPv4) and the fear that somehow he has to keep business going and the lights on while doing it. That scares people. Well, that's my experience anyway. Some days it feels like getting Kuthrapauli to talk to women. We know all he needs to do is talk to them. He can't get past the thought that he has to find a glass of wine first... -- Alan McKinnon Systems Engineer^W Technician Infrastructure Services Internet Solutions +27 11 575 7585 -- Alan McKinnon alan.mckin...@gmail.com
Re: [Bulk] Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 12/03/2013 01:31, Kevin Chadwick wrote: NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. The best real reason for moving to IPV6 is address space (or lack thereof, in the case of IPV4). The people who are truly interested in speeding up IPV6 adoption should do their best to shut up the internet hippies who constantly rant and rave about how NAT is evil. Don't let the cause get distracted by that unrelated issue. Focus on the core issue. I completely agree divide and conquer tactics. You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. NAT was around way earlier and may I state again also that I have externally facing servers and games machines behind NAT. I fail to see your point, and you have answered a question I did not ask. I too have that same circumstance, as likely does every one else here who works in networks for a living. So what? We have that because the environment gives us little choice. It doesn't make it good, bad, desirable or undesirable. it simply is and we have few realistic alternative choices. So are you saying that you think it is good for every machine to be in a DMZ, few chosen ones yes. That's also a question I did not ask, and one I do not care to debate. I disagree completely as I do with the usefullness of push-email. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. NAT has more uses than those two, NAT type of functionality is apparently desired by some ipv6 networks to allow easier ISP migration. You are going to have to back that up with some reasoned arguments. The only reason I can see why some might desire that is their reluctance to give up on old habits. happy to be shown to be wrong though. It's true NAT distracts from the bad points of ipv6 and which is the only part irrelevent for ipv4 modded to work with a larger address space (ipv5). I wonder if this is an example of how these technologies can get so convoluted? McKinnon's Law of Human Implementation of Solutions: Any sufficiently large and representative group of humans when faced with making new choices to solve old problems, will always decide on the most complex convoluted solution that can be implemented soonest. Relevant? I dunno. But it sure sounds good. -- Alan McKinnon alan.mckin...@gmail.com
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/11/2013 06:45 PM, Walter Dnes wrote: On Mon, Mar 11, 2013 at 10:22:39AM +0200, Alan McKinnon wrote You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Agreed. But we shouldn't be pointing out that NAT has partially solved the problem, and giving people false hope that NAT will solve the shortage problem forever. The truth of the matter is that it kinda does, for most of these people. For most of those for whom it doesn't, there are (and will be) plenty of third-party services looking to allow them to throw money at the problem for an opaque solution. (It's like sausage; it works, it's nutritious, it tastes great...but YMMV if you see how it's made.) For small businesses for whom the IP shortage already crowded out of traditional network management, the Cloud was born. Large businesses make a mess of their networks, but hobble along. So workarounds were developed. What NAT has *done*, though, is force a stratification and classification of services, making vast swaths of network applications impossible or incredibly niche. If one doesn't acknowledge the truth of the matter, one gets nailed to the wall with it when someone smart enough to consider it brings it up as a counterpoint. We should be pounding away on the fact that we're running out of IP addresses... period... end of story. If people ask about NAT, then mention that the undersupply will be so bad that even NAT won't help. In my presentations, I've stopped bothering to wait for people to ask about NAT, because it starts off in their minds from nearly the beginning--and until they get that question answered, most of what I say washes past them as ancillary and not as important as the question pressing on their minds. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. That's why I wwant to avoid that propaganda battle. It's been lost already. Deal with it. Don't waste time and effort on it. Put your effort into pounding away on a simple issue that people do understand... we're running out of IP addresses. That's the thing. We're running out, we've *run* out. Past tense. I keep pointing to my friend whose ISP hands him RFC1918 addresses as an example, because that's just the way things are. I can also point to mobile carriers--most local network regions hand out RFC1918 addresses for IPv4, which means you're double-NATting if you use your phone to share your network connection. At one point a couple *years* ago, my T-Mobile phone told me it had what I thought was a public IPv4 address...but it turned out to be an address owned by some security-related branch of the British government who didn't advertise routes, and so T-Mobile was able to use British government netblocks internally as a kind of extension to RFC1918 space. Around the same time, a friend's Verizon phone in the area had a legit public IPv4 address if and only if he was sharing his network connection at that moment...otherwise Verizon would switch him back to an RFC1918 address. So, I say again, we've run out of IPv4 addresses. Past tense. What's left after that is to explain why most of the people you'll ever talk to don't feel pain from it, and explain to them why their anaesthetic is keeping them from realizing their network is paraplegic. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. I disagree with you there. IPV6 adoption will be driven by shortage of addresses, which people can understand. I agree. The problem is that the IPv4 network as it exists today is highly optimized for asymmetric client-server topologies, and the pains and breakages will largely go unnoticed or unattributed due to the layers upon layers of abstractions, band-aids and jerry-rigging. As a consequence, it's necessary to help people understand what they're missing. It will not be accomplished by sermons about the evils of NAT whilst people's eyes glaze over. A preachment, dear friends, you are about to receive, is on John Barleycorn, Nicotine, and the Temptations of NAT. I don't tend to encounter peoples' eyes glazing over. All my presentations are in QA format. There's one guy who's gone to four of them, because, as he told me, it's different every time. And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT being available, rather than no IPV6. Sure. I think IPv6 NAT has its place, but I personally feel it should be done above layer 3, in application-layer gateways. If you're in a scenario where you need IPv6 NAT, you're almost certainly in a scenario where you would benefit from the additional features an ALG would give you. signature.asc Description: OpenPGP
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/11/2013 06:34 PM, Kevin Chadwick wrote: On 03/09/2013 07:53 AM, Kevin Chadwick wrote: There is no reason to believe that IPv6 will result in an increased use of IPsec. Bull. The biggest barrier to IPsec use has been NAT! If an intermediate router has to rewrite the packet to change the apparent source and/or destination addresses, then the cryptographic signature will show it, and the packet will be correctly identified as having been tampered with! http://marc.info/?l=openbsd-miscm=135325641430178w=2 I believe you've misunderstood what Brauer is saying there. NAT needs to process every packets opposed to the !NAT case, where a router doesn't have to process every packet. rrright. Here, when Brauer is talking about processing, he's not talking about tampering with (modifying) packets, he's talking about inspecting them as part of connection state and for other things. This is absolutely distinct from *modifying* the packet, which is what IPsec is intended to detect. I also wouldn't count 'dropping' packets as modification, as: A) an intermediate firewall isn't likely to allow any packet of a stream through to begin with if it's going to block any packet in the stream at all. B) Handling of dropped packets is the responsibility of the transport layer. UDP is supposed to handle it in stride. TCP is supposed to notice and retry. It's hardly difficult to get around that now is it. Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was designed from the beginning to allow you to do things like sign your IP header and encrypt everything else (meaning your UDP, TCP, SCTP or what have you). Setting up a tunnel just so your IP header can be signed wastes another 40 bytes for every non-fragmented packet. Ask someone trying to use data in a cellular context how valuable that 40 bytes can be. You are wrong the biggest barrier is that it is not desirable to do this as there are many reasons for firewalls to inspect incoming packets. I don't agree with things like central virus scanning especially by damn ISPs using crappy Huawei hardware, deep inspection traffic shaping rather than pure bandwidth usage tracking or active IDS myself but I do agree with scrubbing packets. It's not the transit network's job to scrub packets. Do your scrubbing at the VPN endpoint, where the IPSec packets are unwrapped. Trusting the transit network to scrub packets is antithetical to the idea of using security measures to avoid MITM and traffic sniffing attacks in the first place! I never said it was. I was more thinking of IPSEC relaying which would be analogous to a VPN end point but without losing the end-end, neither are desirable, Please, explain to me what the heck you mean, then? When you say You are wrong the biggest barrier is that it is not desirable to do this as there are many reasons for firewalls to inspect incoming packets. I can't possibly understand what you're talking about except with the context you've given me. The only other thing I can take from what you're saying up to this point is that you believe VPNs are bad, which I find, well, laughable. NAT has little to do with the lack of IPSEC deployment. You keep saying this, but saying a thing doesn't make it understood; you have to explain why. What do you gain considering the increased resources, You mean the bandwidth overhead of the ESP and/or AH headers? As opposed to, what, TLS? GRE? IP-in-TLS-in-IP? Let me have a clean, cheap TCP-on-ESP-on-IP stack for my campus-to-campus connections! pointlessly increasing chances of cryptanalysis and pointlessly increasing the chances of exploitation due to the fact that the more complex IPSEC itself can have bugs like Openssl does, If I read your argument correctly, you would view encryption in general as harmful? not to mention amplifying DDOS without the attacker doing anything, which is the biggest and more of a threat than ever, One of my servers is currently undergoing a SYN flood. I'm well aware that the Internet is a dangerous place. Honestly, if someone wants to DDOS you, the increased amplification factor of DNSSEC isn't going to be the deciding factor of whether your server stays up or goes down. or are you going to stop using the internet. Use hyperbole much? When ipv4 can utilise encryption without limitations including IPSEC but more appropriately like ssh just fine when needed you see it is simply not desirable and a panacea that will not happen. You are simply in a bubble as the IETF were. For the purposes of tunnels, I've used IPsec on IPv4, SSH and TLS. Quite frankly? IPsec on IPv6 is the least painful option of all of these. IPsec on IPv4 is frustrating because the VPN clients are poorly implemented, and you *must* use TCP/UDP-in-ESP/AH-in-(optional TCP or UDP in)-IP, or you're not going to get through NAT without getting the network administrator to
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On Mon, Mar 11, 2013 at 11:39:35PM +, Kevin Chadwick wrote Don't waste time and effort on it. Put your effort into pounding away on a simple issue that people do understand... we're running out of IP addresses. We have run out of unallocated ones, there are still loads of unused ones... and even some being released. And they'll run out rather quickly at the rate they're being assigned. There are approximately 3.7 billion usable IPV4 addresses. Soon, that will be one for every 2 people on this planet. And don't forget the people who have an account at home, a smartphone with web access, and an internet-connected desktop at work. Conservation of IP addresses will buy us a couple more years, but that's it. and even more due to global NAT... In another message you said... ...and may I state again also that I have externally facing servers and games machines behind NAT. Yes, that works if *YOU* have at least 1 public IP address and *YOU* control port-forwarding. But it won't work behind carrier-level NAT. It is true eventually it will be an absolute problem but hopefully by then we will have a cleaner ipv7. It won't happen. It's too late to start from scratch, and the IPV6 rollout has already begun. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/11/2013 07:09 PM, Kevin Chadwick wrote: No, there was simply no useful result that came up. Incidentally, both links you provide *did* come up...but I dismissed them because I couldn't imagine anyone using them as a reference except in trying to deride Henning Brauer. http://marc.info/?l=openbsd-miscm=129666298029771w=2 He goes from advocating NAT444 to a spew of pejoratives about something. NAT444 is one of the nastiest, user-disempowering things to hit the Internet to date. The rest of this email is him bitching about having to parse CIDR notation. How disengenuous. He certainly doesn't. Advocacy of NAT444: who sez that your made up isp has to hand out network-wide unique IPs to his customers? Bitching about having to parse CIDR: look at the oh so bright future yourself, look at the code required to deal with that misdesigned piece of shit. did i just say designed? sorry. it's obvious that nothing remotely related to design was involved. Did you miss the sarcasm. Pretty sure I didn't. The only reason he advocates is because others using it allow him to keep running ipv4 pure networks. That's some useful context. After that I'm sure you can forgive me if I note him to have absolutely no reason to be biased and give him a bit more credit and take his experience of writing one of the best and widely used interrupt driven firewalls and so code to deal with ipv6, helping get the netqmail patch sorted and runs his own decent sized network So he's a smart guy with a decent amount of experience. That doesn't make him right. Let me tell you about a similar guy I know. Let's start with my biological father. He started programming as a kid when he got his hands on a 6802 evaluation board, wrote his own operating systems, had a hand in designing the bar code format the US postal service uses for sorting and routing, and provided the local municipality with its first remote electronic monitoring of its water tower. He was one of the first people to jump into Windows NT, with Windows NT 3.51, as he understood the value the NT kernel offered over the DOS-based versions of Windows. He was quite a guy. But he wasn't always right. He *hated* the transition from MFM to IDE drives, as he wasn't able to perform the kinds of diagnostics he wanted to. Once he latched on to Windows NT, he never let go of Microsoft for a second. He didn't see a point to POSIX, UNIX or Linux, and I was never able to get him interested. With the exception of things written or distributed by Microsoft, he never used third-party tools, and had to write everything from the ground-up the way he wanted it. When given specs by other people, he would hand them a product that was what he thought they needed, not what they asked for. He further never felt the need to work with or learn from anyone else in his field. He's brilliant. Quite literally an accomplished genius...but once he got it in his head that he knew what needed to be known, there wasn't room for much new, and there wasn't room for much new. I've tried working with him in architecting web services, and I couldn't. He rejected the idea of using any existing data serialization or transport format, because it wouldn't be as efficient as something he could write. His system architecture relied on a central synchronous component, but the goal of the system was supposed to support scaling. (It couldn't.) Just because he was amazing and awesome among his contemporaries in the past doesn't say anything about his relative skill and knowledge in the present. over yours who I am sure is genuine but could well be partial to ipv6 because as you say you teach setting up ipv6 networks. You need to analyze things on their technical merits, not just on who says them. I won't ask someone to use IPv6 where it's inappropriate. I do believe in pragmatic solutions (systemd and merged /usr notwithstanding ;) ). I don't generally hold for Ludditism. If someone wants to actively reject a technology, I'd like to at least make sure it's for the right reasons. http://marc.info/?l=openbsd-miscm=124536321827774w=2 True enough. And since we're there, it's critical that people learn how to handle their problems. http://marc.info/?l=openbsd-miscm=135325826302392w=2 This email has absolutely no technical content whatsoever. Did you not follow the threads? No. If you want me to read something, you need to point at what I should read. You didn't indicate I should be reading a thread (as opposed to an individual message...) I couldn't find the juicier threads about client troubles due to added complexity but here's some relevent ones and many by very competent devs. (and if I'm honest who tend to shadow every other list I've come across so far as long as you are not timid and can take a hit, though Gentoo is up there). http://marc.info/?l=openbsd-miscm=128822984018595w=2 Re: ARP -- Sure, they don't like ND. That's fine; we
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/10/2013 12:19 AM, Alan McKinnon wrote: On 10/03/2013 03:42, Walter Dnes wrote: On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote The trouble with NAT is that it destroys peer-to-peer protocols. The first was FTP in Active mode. In its day, it was OK. Nowadays, we use passive mode. What's the problem? SIP has been heavily damaged as well. Anyone who's used IRC is familiar with the problems NAT introduces to DCC. Every ADSL router-modem I've run into recently has port-forwarding. Anyone who's ever played video games online,... A *CLIENT* that can't operate from behind NAT is totally brain-dead. or who's tried hosting a Teamspeak or Ventrillo server, has had NAT get in their way as well. Port-forwarding. All those examples you give are much like a bunch of home machines sitting behind a NAT gateway onto the internet. That's actually OK and I reckon that is the intended use of NAT. I want to point out that that's only true if the home network has at least one public IP. If you've got NAT 4x4, you're kinda screwed. (Alan will understand that, but for those unfamiliar with it, that basically means that if your home router is given an RFC1918 address by your ISP, port forwarding isn't going to do squat for you.) I've got a friend in a rural area who can't get a publicly-routable address. To access his home network from work, he rents a VPS and sets up a static tunnel. Such are the evils of NAT. Personally, I'd prefer all of my machines to have a public address but there's no chance in hell my NetOps colleagues are giving me that with my DSL connection. Well, with IPv6, they're supposed to. ^^ We have any years of experience now with consumer connections and the users that use them, these guys mostly can't admin a machine to save their lives, so NAT in their case is a good thing on balance. There's nothing NAT really offers them that having a default simple firewall on their network gateway wouldn't solve. If inbound traffic is part of an established or related connection, accept it. Otherwise, reject it by default. That's all the security benefit NAT accomplishes, albeit without mangling any packets. The true evil of NAT comes about when some clown starts implementing it on the network itself. I'm in city X, we have a large office in city Y, and most of the traffic Y-X goes through a *router* doing NAT. No-one knows anymore why this was originally done but we all know what it will take to undo it. To get our backend systems to work for client in city Y I have to put in the cursed any any firewall rules, and that sends our Risk fellows ballistic for good reason. But I have no choice, the network design essentially discarded all information as to who the client is, so now I must allow all of them. Any real-life network that grew organically over several years is always going to be rife with examples of fuck ups like this, always done in the name of expediency. I have lots of such examples, the above is only the first that came to mind. So whereas NAT behind a home router for IPv4 is good, in almost every other usage I've seen it is bad and really just a case of a solution used in places it never ever belonged. NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. (It's unfortunate we never got DHCP-PD for IPv4; that would solve a number of problems I've seen and foresee with small-business IPv4 networks both pre- and post-crunch.) signature.asc Description: OpenPGP digital signature
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/09/2013 07:53 AM, Kevin Chadwick wrote: Lookup ipvshit I'll give you a hint. The guy who wrote most of the pf firewall that MAC OSX now uses as well as QNX, the latest version originating from OpenBSD and being far better than iptables has bought up lots of ipv4 just to stay away from ipvshit. Tried searching for it. You're going to have to provide some useful direct reference, because a basic search wasn't very illuminating. Perhaps Google doesn't approve of swear words?! No, there was simply no useful result that came up. Incidentally, both links you provide *did* come up...but I dismissed them because I couldn't imagine anyone using them as a reference except in trying to deride Henning Brauer. http://marc.info/?l=openbsd-miscm=129666298029771w=2 He goes from advocating NAT444 to a spew of pejoratives about something. NAT444 is one of the nastiest, user-disempowering things to hit the Internet to date. The rest of this email is him bitching about having to parse CIDR notation. http://marc.info/?l=openbsd-miscm=135325826302392w=2 This email has absolutely no technical content whatsoever. signature.asc Description: OpenPGP digital signature
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 10/03/2013 23:07, Michael Mol wrote: All those examples you give are much like a bunch of home machines sitting behind a NAT gateway onto the internet. That's actually OK and I reckon that is the intended use of NAT. I want to point out that that's only true if the home network has at least one public IP. If you've got NAT 4x4, you're kinda screwed. (Alan will understand that, but for those unfamiliar with it, that basically means that if your home router is given an RFC1918 address by your ISP, port forwarding isn't going to do squat for you.) I'm getting images of NATted traffic being NATted. My head just exploded. -- Alan McKinnon alan.mckin...@gmail.com
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/09/2013 07:53 AM, Kevin Chadwick wrote: There is no reason to believe that IPv6 will result in an increased use of IPsec. Bull. The biggest barrier to IPsec use has been NAT! If an intermediate router has to rewrite the packet to change the apparent source and/or destination addresses, then the cryptographic signature will show it, and the packet will be correctly identified as having been tampered with! It's hardly difficult to get around that now is it. Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was designed from the beginning to allow you to do things like sign your IP header and encrypt everything else (meaning your UDP, TCP, SCTP or what have you). Setting up a tunnel just so your IP header can be signed wastes another 40 bytes for every non-fragmented packet. Ask someone trying to use data in a cellular context how valuable that 40 bytes can be. You are wrong the biggest barrier is that it is not desirable to do this as there are many reasons for firewalls to inspect incoming packets. I don't agree with things like central virus scanning especially by damn ISPs using crappy Huawei hardware, deep inspection traffic shaping rather than pure bandwidth usage tracking or active IDS myself but I do agree with scrubbing packets. It's not the transit network's job to scrub packets. Do your scrubbing at the VPN endpoint, where the IPSec packets are unwrapped. Trusting the transit network to scrub packets is antithetical to the idea of using security measures to avoid MITM and traffic sniffing attacks in the first place! With IPsec, NAT is unnecessary. (You can still use it if you need it...but please try to avoid it!) Actually it is no problem at all and is far better than some of the rubbish ipv6 encourages client apps to do. (See the links I sent in the other mail) Please read the links before you send them, and make specific references to the content you want people to look at. I've read and responded to the links you've offered (which were links to archived messages on mailing lists, and the messages were opinion pieces with little (if any) technical material.) Re DNS support for IPv6 Increased size of DNS responses due to larger addresses might be exploited for DDos attacks That's not even significant. Have you looked at the size of DNS responses? The increased size of the address pales in comparison to the amount of other data already stuffed into the packet. It's been ages since I looked at that link and longer addresses would certainly be needed anyway but certainly with DNSSEC again concocted by costly unthoughtful and unengaging groups who chose to ignore DJB and enable amplification attacks. What from DJB did they ignore? I honestly don't know what you're talking about. His latest on the DNS security mess http://cr.yp.to/talks/2013.02.07/slides.pdf I've never before in my life seen someone animate slideshow transitions and save off intermediate frames as individual PDF pages. That was painful. So, I read what was discussed there. First, he describes failings of HTTPSEC. I don't have any problem with what he's talking about there, honestly; it makes a reasonable amount of sense, considering intermediate caching servers aren't very common for HTTP traffic, and HTTPS traffic makes intermediate caching impossible. (unless you've already got serious security problems by way of a MITM opening.) Then he turns around and dedicates two slides showing a DNS delegation sequence...and then states in a single slide that DNSSEC has all the same problems as HTTPSEC. DNSSEC doesn't have the same problems as HTTPSEC, because almost *every* recursive resolving DNS server (which is most of the DNS servers on the Internet) employs caching. An attacker can connect to an IPv4-only network, and forge IPv6 Router Advertisement messages. (*) Again, this depends on them being on the same layer 2 network segment. The same class of attacks would be possible for any IPv4 successor that implemented either RAs or DHCP. Neither of which I use. You're telling me you don't use DHCP? Seriously, that you statically configure the IPv4 addresses of all the hosts on your network? With one exception, I haven't personally seen a network configured in that way since 1998! Certainly, every network has some hosts configured statically, but virtually no network I've observed (and I've seen private networks between 2 and 50 hosts, and commercial networks between 5 and 30k hosts) managed completely statically. As I said we would be here all day and that link wasn't as good as the one I was actually looking for. local NAT done right is no problem and actually a good thing and I have no issues playing games, running servers or anything else behind NAT. See others' responses about port standardization, and about how it enforces a distinction between 'clients' and 'servers' that's unnecessary (and even
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/10/2013 05:43 PM, Alan McKinnon wrote: On 10/03/2013 23:07, Michael Mol wrote: All those examples you give are much like a bunch of home machines sitting behind a NAT gateway onto the internet. That's actually OK and I reckon that is the intended use of NAT. I want to point out that that's only true if the home network has at least one public IP. If you've got NAT 4x4, you're kinda screwed. (Alan will understand that, but for those unfamiliar with it, that basically means that if your home router is given an RFC1918 address by your ISP, port forwarding isn't going to do squat for you.) I'm getting images of NATted traffic being NATted. My head just exploded. Yup. That's the state of small residential ISPs right now, and why it's so critical to get IPv6 deployed. signature.asc Description: OpenPGP digital signature
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2013 06:00 PM, Michael Mol wrote: It's been ages since I looked at that link and longer addresses would certainly be needed anyway but certainly with DNSSEC again concocted by costly unthoughtful and unengaging groups who chose to ignore DJB and enable amplification attacks. What from DJB did they ignore? I honestly don't know what you're talking about. This was a non-sequitur as far as I can tell, but I remember the amplification attack from a talk: http://vimeo.com/18279777 (video) http://cr.yp.to/talks/2010.12.28/slides.pdf (slides) It was a really good talk, however you feel about DJB. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRPTnkAAoJEBxJck0inpOia6EP/1Bu1rhx5cCi6/bl/J3MeJm3 CAaGXQG6iSnxxIXVqVXTs2fioZH2f3Xsq3jvKBoAQfil2ocGQa4LAPSGbLYX99xr XodEfm530EDK02UsqnyGHX2pzFQzUR/cQ0/SFpd8tMtEiYRdASIT6VtqoJoQWsoA unvPvK6xxHhH/YwmB+miPUSVl1nvmqT6Z7OKmpQL+MRHCQFvyk7SeClVf8OmAPkn NX/m3pSbsHdAtj6QP6CU8nAF1QbgWehhvZkx8UxqwPz8n8AO1JfY+zG669B5F6u+ MRcnN1s6jgIVoAgeqvgDjUC8JnkQTGBg3Lkdrv9IcM7N/+4ILvlH6h3IeSiI6unU hnganpVCl0q03N+qRi3JsHfdR/ZNBEetkplOai/QKyUltKohGG4LLPbqBFEdg+NP nVWz/Y4wn3h2uasClfIbehxSQDKlbHCvKOLp/dEmcFsra29vAF3pu15V1okmqdwF qzwf1k7nxoyjCT4YVnQv7F9OwnyYwm3nEmOjQyShJZN3gN82/4b+1R0LyhjeOled WcF8dnuxNpITjr1OusQ9MUeYmotWX2dj+//6zsrwZVs3QTNyOHx5VVe9Bl3DdcKr lFthQKyjsQAGgMD7zFoy4JxPReBwTQhu/QGcGKVKLIVRlTJ0XRQWVHUijlVY6dqB lIZu+xpwtY8OeZ20e+BC =knjT -END PGP SIGNATURE-
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/10/2013 09:56 PM, Michael Orlitzky wrote: On 03/10/2013 06:00 PM, Michael Mol wrote: It's been ages since I looked at that link and longer addresses would certainly be needed anyway but certainly with DNSSEC again concocted by costly unthoughtful and unengaging groups who chose to ignore DJB and enable amplification attacks. What from DJB did they ignore? I honestly don't know what you're talking about. This was a non-sequitur as far as I can tell, but I remember the amplification attack from a talk: http://vimeo.com/18279777 (video) http://cr.yp.to/talks/2010.12.28/slides.pdf (slides) It was a really good talk, however you feel about DJB. Didn't watch the video, but I did read the slide deck. It's a good read, even if I disagree with a number of key points, disagree with the tack taken as a solution, and further think the presenter cherry-picked his arguments, amplified inconsequential pieces of the problem space and skipped over obvious problems with his approach. (Hm. I suspect I'm formulating an opinion on DJB, and I didn't have one a couple hours ago...) (That said, he does seem to know how to use slide decks properly!) I believe Kevin's position is that, while I cited secure your DNS in response to some of the arguments raised by a slide deck he linked to, securing your DNS would likely involve using DNSSEC, which DJB argues enable amplification attacks. signature.asc Description: OpenPGP digital signature
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On Sun, Mar 10, 2013 at 05:07:25PM -0400, Michael Mol wrote NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. The best real reason for moving to IPV6 is address space (or lack thereof, in the case of IPV4). The people who are truly interested in speeding up IPV6 adoption should do their best to shut up the internet hippies who constantly rant and rave about how NAT is evil. Don't let the cause get distracted by that unrelated issue. Focus on the core issue. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/11/2013 12:00 AM, Walter Dnes wrote: On Sun, Mar 10, 2013 at 05:07:25PM -0400, Michael Mol wrote NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. The best real reason for moving to IPV6 is address space (or lack thereof, in the case of IPV4). The people who are truly interested in speeding up IPV6 adoption should do their best to shut up the internet hippies who constantly rant and rave about how NAT is evil. Don't let the cause get distracted by that unrelated issue. Focus on the core issue. They're two sides of the same coin. If NAT wasn't such a problem, layering RFC1918 address space would solve most of the address space problems. The address space crunch remains a technical problem largely because NAT can't solve it to completion. NAT forces a distinction between 'client' and 'server', breaking the 'peer' nature of the network. This isn't some hippy egalitarian thing, it means I can't trivially tell my VPS to connect to a backup target on a different network without setting up either a tunnel or a port forward. With IPv6, doing this is so brain-dead easy I never want to be without it again. Once you've experienced IPv6 and appropriate network firewalls, along with the ease of connecting to your own machines from anywhere you want without having to bounce through a third-party management service like Teamviewer, you never want to go back. It's like discovering you've been holding a pencil wrong all your life, or like discovering a better way to tie your shoes; the solution is simple, elegant and surprisingly productive. NAT is like tying your shoes wrong; you don't know how much of a problem it is until you experience life without it. And even once you get people comfortable with deploying IPv6, they still want to hold on to NAT; it's like a stubborn stain on their minds. It's important to explain that NAT isn't a security measure. In order to operate, it requires what amounts to a stateful firewall...but that doesn't mean that a stateful firewall is difficult to obtain without NAT. People have grown so accustomed to the presence of NAT and NAT's inherent implications on inbound traffic that they wind up conflating the two in their minds, making actual understanding of their network's security that much more difficult to comprehend. So, yeah, NAT is evil. Looking for privacy in your addresses? That's what privacy extensions are for, and they're enabled by default on Windows and Ubuntu. (I haven't looked on Gentoo...) The only reasonably valid use case for NAT that I've seen is for dealing with the question of multi-homing an office with two internet connections. The idea is that you don't have to renumber your internal network if you need to switch from your primary connection to your backup connection (and you're being granted different IP ranges based on which connection you're working with...so we're talking small business, not BGP or multilink with the same ISP). In those cases, I advocate application-layer gateways; chances are, if you're investing in multi-homing your office, you probably already want the kind of administrative power (and performance improvements) proxy servers can offer you. The IPv4 address crunch triggered the development of DNAT a couple decades ago, and the silly thing persists in terrible ways when there are simpler ways to handle things. (When I say 'simpler', I mean: Don't break assumptions about basic network behavior such as 'don't mangle my packets' or 'I can open a connection back to him when I have updates he needs') signature.asc Description: OpenPGP digital signature
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
There is no reason to believe that IPv6 will result in an increased use of IPsec. Bull. The biggest barrier to IPsec use has been NAT! If an intermediate router has to rewrite the packet to change the apparent source and/or destination addresses, then the cryptographic signature will show it, and the packet will be correctly identified as having been tampered with! It's hardly difficult to get around that now is it. You are wrong the biggest barrier is that it is not desirable to do this as there are many reasons for firewalls to inspect incoming packets. I don't agree with things like central virus scanning especially by damn ISPs using crappy Huawei hardware, deep inspection traffic shaping rather than pure bandwidth usage tracking or active IDS myself but I do agree with scrubbing packets. With IPsec, NAT is unnecessary. (You can still use it if you need it...but please try to avoid it!) Actually it is no problem at all and is far better than some of the rubbish ipv6 encourages client apps to do. (See the links I sent in the other mail) Re DNS support for IPv6 Increased size of DNS responses due to larger addresses might be exploited for DDos attacks That's not even significant. Have you looked at the size of DNS responses? The increased size of the address pales in comparison to the amount of other data already stuffed into the packet. It's been ages since I looked at that link and longer addresses would certainly be needed anyway but certainly with DNSSEC again concocted by costly unthoughtful and unengaging groups who chose to ignore DJB and enable amplification attacks. His latest on the DNS security mess http://cr.yp.to/talks/2013.02.07/slides.pdf An attacker can connect to an IPv4-only network, and forge IPv6 Router Advertisement messages. (*) Again, this depends on them being on the same layer 2 network segment. The same class of attacks would be possible for any IPv4 successor that implemented either RAs or DHCP. Neither of which I use. As I said we would be here all day and that link wasn't as good as the one I was actually looking for. local NAT done right is no problem and actually a good thing and I have no issues playing games, running servers or anything else behind NAT. Global NAT works well enough but isn't a good thing and wouldn't exist if they had simply added more addresses quickly. The hardware uptake would have been no issue rather than a decade of pleads. We haven't even touched on the code yet and so all the vulnerable especially home hardware which yes often has vulnerable sps anyway but by no way just home hardware. The ipvshit links give an insight into the code complexity. Note OpenBSDs kernel which is very secure (unlike Linux whose primary goal is function) and has had just a few remote holes in well over a decade, one of which was in ipv6 and which I had avoided without down time because I won't and what's more shouldn't use ipv6 wherever possible and had actually removed it from the kernel all together. If I am Trolling rather than simply trying to make people aware then stating ipv6 is wonderful is Trolling just as much or more. Regards, Kc -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
Lookup ipvshit I'll give you a hint. The guy who wrote most of the pf firewall that MAC OSX now uses as well as QNX, the latest version originating from OpenBSD and being far better than iptables has bought up lots of ipv4 just to stay away from ipvshit. Tried searching for it. You're going to have to provide some useful direct reference, because a basic search wasn't very illuminating. Perhaps Google doesn't approve of swear words?! http://marc.info/?l=openbsd-miscm=129666298029771w=2 http://marc.info/?l=openbsd-miscm=135325826302392w=2 -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/09/2013 08:42 PM, Walter Dnes wrote: On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote The trouble with NAT is that it destroys peer-to-peer protocols. The first was FTP in Active mode. In its day, it was OK. Nowadays, we use passive mode. What's the problem? It also doesn't work under NAT, it's just broken in the other direction. SIP has been heavily damaged as well. Anyone who's used IRC is familiar with the problems NAT introduces to DCC. Every ADSL router-modem I've run into recently has port-forwarding. Anyone who's ever played video games online,... A *CLIENT* that can't operate from behind NAT is totally brain-dead. But you must have one non-NATed server for anything to work. I assume that's what was meant by it destroys peer-to-peer protocols. You have to draw an arbitrary distinction between machines that work together, servers, and ones that don't, clients. The problem will become more and more apparent as ipv4 space dries up and everyone becomes a client. Although ISPs will be more than happy to sell you a useful connection, for a premium. Un-NATed addresses are like, type-O blood. Imagine how much better off we'd be if we could get everyone to switch their blood to type-O. Might be less painful than the ipv6 transition, too =) or who's tried hosting a Teamspeak or Ventrillo server, has had NAT get in their way as well. Port-forwarding. Port forwarding can work, but only for one host when the ports are standardized. You can't forward e.g. port 443 to two hosts, so only one host behind the NAT can be accessible on 443. If you're using your NAT as a firewall for one box, then who cares. But you can't put more than one machine behind it and have everything still work.
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 10/03/2013 03:42, Walter Dnes wrote: On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote The trouble with NAT is that it destroys peer-to-peer protocols. The first was FTP in Active mode. In its day, it was OK. Nowadays, we use passive mode. What's the problem? SIP has been heavily damaged as well. Anyone who's used IRC is familiar with the problems NAT introduces to DCC. Every ADSL router-modem I've run into recently has port-forwarding. Anyone who's ever played video games online,... A *CLIENT* that can't operate from behind NAT is totally brain-dead. or who's tried hosting a Teamspeak or Ventrillo server, has had NAT get in their way as well. Port-forwarding. All those examples you give are much like a bunch of home machines sitting behind a NAT gateway onto the internet. That's actually OK and I reckon that is the intended use of NAT. Personally, I'd prefer all of my machines to have a public address but there's no chance in hell my NetOps colleagues are giving me that with my DSL connection. We have any years of experience now with consumer connections and the users that use them, these guys mostly can't admin a machine to save their lives, so NAT in their case is a good thing on balance. The true evil of NAT comes about when some clown starts implementing it on the network itself. I'm in city X, we have a large office in city Y, and most of the traffic Y-X goes through a *router* doing NAT. No-one knows anymore why this was originally done but we all know what it will take to undo it. To get our backend systems to work for client in city Y I have to put in the cursed any any firewall rules, and that sends our Risk fellows ballistic for good reason. But I have no choice, the network design essentially discarded all information as to who the client is, so now I must allow all of them. Any real-life network that grew organically over several years is always going to be rife with examples of fuck ups like this, always done in the name of expediency. I have lots of such examples, the above is only the first that came to mind. So whereas NAT behind a home router for IPv4 is good, in almost every other usage I've seen it is bad and really just a case of a solution used in places it never ever belonged. -- Alan McKinnon alan.mckin...@gmail.com
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
1. The craziness of trying to conserve IPv4 space 2. NAT. Finally, a good solid techical reason to make NAT just go away and stay away. Permanently. Forever. It's a great shame that isn't all it fixed (ipv5), then your job wouldn't have been so hard and there wouldn't be any reason for many of us to cling to ipv4 of which there are many strong reasons that are far far worse than NAT. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/08/2013 02:50 PM, Kevin Chadwick wrote: 1. The craziness of trying to conserve IPv4 space 2. NAT. Finally, a good solid techical reason to make NAT just go away and stay away. Permanently. Forever. It's a great shame that isn't all it fixed (ipv5), then your job wouldn't have been so hard and there wouldn't be any reason for many of us to cling to ipv4 of which there are many strong reasons that are far far worse than NAT. IPv5 never really existed. http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html signature.asc Description: OpenPGP digital signature
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
1. The craziness of trying to conserve IPv4 space 2. NAT. Finally, a good solid techical reason to make NAT just go away and stay away. Permanently. Forever. It's a great shame that isn't all it fixed (ipv5), then your job wouldn't have been so hard and there wouldn't be any reason for many of us to cling to ipv4 of which there are many strong reasons that are far far worse than NAT. IPv5 never really existed. http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html First I've heard of ST or an actual ipv5 but sounds like they had dropped a layer. Having options like tcp or udp is a good thing. What would have been best, could have been done years ago and not cost lots of money and even more in security breaches and what I meant by ipv5 and would still be better to switch to even today with everyone being happy to switch to it is simply ipv4 with more bits for address space. If I got an ISP who only offers me IPV6 I would drop the ISP before the IPV4! -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On Mar 9, 2013 4:51 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: 1. The craziness of trying to conserve IPv4 space 2. NAT. Finally, a good solid techical reason to make NAT just go away and stay away. Permanently. Forever. It's a great shame that isn't all it fixed (ipv5), then your job wouldn't have been so hard and there wouldn't be any reason for many of us to cling to ipv4 of which there are many strong reasons that are far far worse than NAT. IPv5 never really existed. http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html First I've heard of ST or an actual ipv5 but sounds like they had dropped a layer. Having options like tcp or udp is a good thing. What would have been best, could have been done years ago and not cost lots of money and even more in security breaches and what I meant by ipv5 and would still be better to switch to even today with everyone being happy to switch to it is simply ipv4 with more bits for address space. If I got an ISP who only offers me IPV6 I would drop the ISP before the IPV4! Unfortunately, your logic is flawed. Where would you put the additional bits of address? That would involve rewriting the IP Header. And while we're at it, why not *totally* remake IP based on decades of observation experience? Hence, IPv6. Rgds, --
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On Fri, Mar 08, 2013 at 09:49:23PM +, Kevin Chadwick wrote What would have been best, could have been done years ago and not cost lots of money and even more in security breaches and what I meant by ipv5 and would still be better to switch to even today with everyone being happy to switch to it is simply ipv4 with more bits for address space. This should be FAQ entry zero for the IPV6 FAQ... *NO* you can *NOT* add more bits to IPV4, and still have it backwards compatable. It won't work... period... end of story. Every piece of hardware and software that deals with IPV4 has the concept of 32 bits *HARD-CODED* into it. Switching over to IPV4-extended would be just as painfull as switching over to IPV6. We will be running out of IPV4 address space shortly so we do need to upgrade. Having said that, I don't understand all the hate for NAT. At the risk of being called an elitist, I'll say that 95% of average internet users have no business running servers; heck many of them can't even keep *CLIENTS* properly secured. If IPV6-NAT in my home causes me any problem, that's my problem. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
What would have been best, could have been done years ago and not cost lots of money and even more in security breaches and what I meant by ipv5 and would still be better to switch to even today with everyone being happy to switch to it is simply ipv4 with more bits for address space. This should be FAQ entry zero for the IPV6 FAQ... *NO* you can *NOT* add more bits to IPV4, and still have it backwards compatable. It won't work... period... end of story. Every piece of hardware and software that deals with IPV4 has the concept of 32 bits *HARD-CODED* into it. Switching over to IPV4-extended would be just as painfull as switching over to IPV6. No it would not, the headers would be different. All the hardware would have already updated because there would be no bad sides and it would have been released something like 15 years ago. But lets not discuss them as we would be here for an eternity and there are already whole websites dedicated to just that. I re-iterate it would be worth hardware not being backwards compatible again to go to ipv4 with large address space today. http://www.hackingipv6networks.com/past-trainings/hip2011-hacking-ipv6-networks.pdf That's just on security. There's a whole bad side to it's functionality too. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
Unfortunately, your logic is flawed. Where would you put the additional bits of address? That would involve rewriting the IP Header. Your assumption that I do not know that is flawed. I did a review of ipv6 before it was released and determined ipv4 to be superior then. That was before I was shown some of the bad sides more recently. And while we're at it, why not *totally* remake IP based on decades of observation experience? Who's observations and who's experience. Not everyones that's for damn sure. Hence, IPv6. Lookup ipvshit I'll give you a hint. The guy who wrote most of the pf firewall that MAC OSX now uses as well as QNX, the latest version originating from OpenBSD and being far better than iptables has bought up lots of ipv4 just to stay away from ipvshit. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/08/2013 07:45 PM, Kevin Chadwick wrote: What would have been best, could have been done years ago and not cost lots of money and even more in security breaches and what I meant by ipv5 and would still be better to switch to even today with everyone being happy to switch to it is simply ipv4 with more bits for address space. This should be FAQ entry zero for the IPV6 FAQ... *NO* you can *NOT* add more bits to IPV4, and still have it backwards compatable. It won't work... period... end of story. Every piece of hardware and software that deals with IPV4 has the concept of 32 bits *HARD-CODED* into it. Switching over to IPV4-extended would be just as painfull as switching over to IPV6. No it would not, the headers would be different. All the hardware would have already updated because there would be no bad sides and it would have been released something like 15 years ago. But lets not discuss them as we would be here for an eternity and there are already whole websites dedicated to just that. I don't know, you just dropped the 2-3 most trollish anti-IPv6 posts I've ever seen. I re-iterate it would be worth hardware not being backwards compatible again to go to ipv4 with large address space today. IPv4 with large address space would have taken just as long to deploy; it's the hardware support that's held us back the most. http://www.hackingipv6networks.com/past-trainings/hip2011-hacking-ipv6-networks.pdf That's just on security. There's a whole bad side to it's functionality too. Let's discuss security. I'll walk through the slide deck. We have much less experience with IPv6 than with IPv4 That's a meaningless statement... IPv6 implementations are much less mature than their IPv4 counterparts. Only in hardware Software has been much better. Windows has had full IPv6 support since Vista. Linux has had full IPv6 support for a few years, including IPSec. The software implementations are written...the stuff that's still arriving is feature-add. Offload engines and managed switches haven't switched over because clients were more interested in putting off a transition (the same transition you'd have to go through for IPv4 with extended address space) than paying for the upgrades. This would have happened with any IPv4 replacement. Security products (firewalls, NIDS, etc.) have less support for IPv6 than for IPv4 Dedicated commercial products, yes. General-purpose products? Like I said, Windows Vista made IPv6 a first-class protocol, including firewall support. Linux's implementation is a bit quirky. I don't care for the separation between iptables and ip6tables; I think people tend to write an iptables script and forget to set up a firewall of any kind for IPv6. Most of the builder tools (i.e. fwbuilder), require seperate setup between the two, too. That's why I use sanewall (formerly firehol); defined rules apply to both IPv4 and IPv6. The complexity of the resulting network will greatly increase during the transition/co-existence period: Yes, and that would apply to any transition period. Lack of trained human resources That's why people like me go out and do training sessions. (I'll be at Penguicon again this year, if anyone else was thinking about going...) That's why Hurricane Electric offers free online certification programs. Regarding flow labels: Currently unused by many stacks – others use it improperly Honestly, I don't know about this. It's not something most people will need to work with. Might be leveraged to perform “dumb” (stealth) address scans I don't understand the relevance; you get the same information by observing the packet flow without the flow label. Might be leveraged to perform Denial of Service attacks So might absolutely anything. Regarding hop limit: Could be leveraged for Detecting the Operating System of a remote node So can IPv4's TTL, which it's analogous to. Could be leveraged for Fingerprinting a remote physical device So can IPv4's TTL, which it's analogous to. Could be leveraged for Locating a node in the network topology tcptraceroute does this with IPv4 TTLs. And traceroute has been doing this with IPV4's ICMP echo for decades. Could be leveraged for Evading Network Intrusion Detection Systems (NIDS) Just like IPv4 TTL. Could be leveraged for Reducing the attack exposure of some hosts/applications Not sure what's being said here, but we're talking about a feature directly analogous to IPv4 TTL. (skipping the remainder of the section, as there's nothing in there that's bad that's unique to IPv6) (skipping the next several sections, as they're just general technical training material, and don't discuss security implications) Re Fragmentation security implications that are different from IPv4: The Identification field is much larger: chances of “IP ID collisions” are reduced Good thing. Note: Overlapping fragments have been recently forbidden (RFC 5722) – but they are still allowed by many
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/08/2013 07:50 PM, Kevin Chadwick wrote: Unfortunately, your logic is flawed. Where would you put the additional bits of address? That would involve rewriting the IP Header. Your assumption that I do not know that is flawed. I did a review of ipv6 before it was released and determined ipv4 to be superior then. That was before I was shown some of the bad sides more recently. And while we're at it, why not *totally* remake IP based on decades of observation experience? Who's observations and who's experience. Not everyones that's for damn sure. This is why the IETF exists, to allow vendors and engineers with field knowledge to argue and debate until they come up with something that most of them can agree on. IPv6 is what came out of that process. I'm not going to say IPv6 doesn't have flaws...but it's certainly a lot better than IPv4, and features it adds (even beyond address space expansion) are very nice. Hence, IPv6. Lookup ipvshit I'll give you a hint. The guy who wrote most of the pf firewall that MAC OSX now uses as well as QNX, the latest version originating from OpenBSD and being far better than iptables has bought up lots of ipv4 just to stay away from ipvshit. Tried searching for it. You're going to have to provide some useful direct reference, because a basic search wasn't very illuminating. signature.asc Description: OpenPGP digital signature
