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 Oses" This will improve. "IPv6 Idle scan" Noted as being applicable to IPv4. (skipping some general technical material aimed at sysadmin use for securing their systems) (skipping description of IPv6 headers; basic technical information) (skipping suggested countermeasures for theorized attacks) "IPv6 can be easily leveraged for evading firewalls." Not if the firewall is set up properly to begin with. Part of that is described in the preceding 'countermeasures' section. Most of the remainder is leveraging the same source, dest, port and state data that's known in IPv4. Finally, use IPSec if possible. (Right now, IPSec is largely useful as a VPN technique natively supported by by layer 3) "Most likely, firewalls will block packets with extension headersEs muy probable que se haga común el filtrado (en firewalls) de paquetes que contengan en encabezados de extensión" Not really; firewalls will continue to be based on known factors, and most of the interesting known factors are in the first header, not the extension headers. "The result will be: less flexibility, possibly preventing any use of IPv6 exntesion headers" Extension headers will be used where appropriate. (skip more benign material) "Some ICMPv6 messages are assumed to indicate “hard errors”. Some stacks used to abort TCP connections when hard errors were received. BSD-derived and Linux implementations don’t--Good!" I believe Windows's stack is based on BSD. I don't know of any stacks which do. (None are listed, either) (skip portion which notes straightforward solutions) (skip benign material) Re ICMPv6 Echo Request/Echo response "Also usually exploited for network reconnaissance" A.K.A. 'traceroute', a known entity in IPv4. (skip benign material) Re Node Information Query/Response "My take: unless you really need your nodes to support Node Information messages, disable it (i.e., “sysctl –w net.inet6.icmp6.nodeinfo=0)." Or even firewall it off at your network edge, like you would any unblessed, unsolicited inbound traffic. (skip benign material) Re Address Resolution Games "Neighbor Cache Poisoning attacks – the v6 version of V4’s ARP cache poisoning" Says it for me...same as IPv4's ARP poisoning. (Incidentally, this is the attack bandied about the most by people arguing that IPv6 is insecure) "Advertising “special” link-layer addresses, e.g.," That's probably a bug in the implementation. It will be fixed. "Some implementations (FreeBSD, NetBSD) don’t enforce limits on the number of entries that can be created in the Neighbor Cache" Certainly that will change soon. (Skipping MitM and DoS discussion, as it's analogous to IPv4's ARP poisoning) "Not much support in layer-2 security boxes to mitigate these attacks" This is improving. It hadn't shown up yet because commercial purchasers had been dragging their feet in demanding their vendors support IPv6 in the first place. (skip more benign material) "Disable an Existing Router" Depends on the attacker being on the local network, and is what RAGuard is for. "Exploit DAD for Denial of Service" This is the first interesting attack I've seen mentioned in the slide deck (and I'm on slide 109 out of 167, getting to it). I don't think there's a way to mitigate against it, except to prevent the attacker from getting on layer 2 network in the first place. (Entirely doable with things like 802.1x.) "Advertise Malicious Network Parameters" Again, what RAGuard is for. Re Autoconf Addresses & Privacy "There were concerns that autoconf addresses hurt privacy, as they could be used to correlate network activity" Not all that interesting, actually. That kind of correlating activity is happening more effectively with DPI and HTTP request headers, and *that* sees through NAT, privacy addresses and proxy servers. When people express concerns about autoconf addresses to me, I tell them that if they're that worried about it, they need to already be using source-obfuscating techniques like the Tor network. (skip benign material) "The use of a single “Destination Options” header is enough to evade most implementations of RA-Guard." Sadly, that's on the hardware vendors again. Hopefully, the commercial-grade vendors will get their crap patched. There's no reason (that I know of) for an RA-Guard implementation to need to inspect the destination options header. "This technique can also be exploited to circumvent Neighbor Discover monitoring tools such as NDPMon" I don't know so much about this attack, honestly. Re DHCPv6 "It can be exploited in a similar way to Router Advertisement messages." And protected in the same way. Re MLD "Potential issues: If a MLD-snooping switch is employed, MLD could be exploited for Denial of Service attacks." Largely the same class of attacks as if the attacker is on the local segment. Enable MLD snooping if and only if you're willing to expand your attack surface in that way. That's not a difficult question; it's similar to asking whether you want to use a wireless bridge to a wired network, or if you want to use a router instead. Re IPSec "IPsec support is currentlymantatory for IPv6 implementations – the IETF is changing this requirement to “optional” thus acknowledging reality." I have yet to encounter a widely-used IPv6 stack that does not support IPSec. *BSD, Linux and Windows all support it. The idea of it being "optional" is irrelevant to the question of whether it's available for use by servers and desktop machines. "Also, many IPv4 implementations support IPsec, while many IPv6 implementations do not." As I said, I have yet to encounter a widely-used IPv6 stack that doesn't support IPSec. Actually, I haven't encountered *any* IPv6 stack that doesn't support IPSec. I imagine the ones that don't are in things like voip phones. "Most of the key problems (e.g., PKI) for IPsec deployment in IPv4 apply to IPv6, as well." This is true, if you want to use PKI for IPSec deployment. If you're setting up static relationships between campus endpoints, it's not so big a deal. "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! With IPsec, NAT is unnecessary. (You can still use it if you need it...but please try to avoid it!) 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. Re "IPv6 Transition Co-Existence Technologies" "Original transition plan: deploy IPv6 before we ran out of IPv4 addresses, and eventually turn off IPv4 when no longer needed – it didn’t happen" That's correct; the IPv6 deployment didn't happen when it should have. Instead, a ton of coping mechanisms for a shrinking address pool came around. NAT is the big one. If IPv6 had been deployed early on, people wouldn't think of "one IP address per customer" as the norm...and they shouldn't have to. "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. (Yes, you will want to deploy the countermeasures described) (skipping more benign material) Re ISATAP "An attacker could forge name resolution responses to--" Secure your DNS. "This could be used in conjunction with other attacks (e.g. forging DNS responses such that--" Secure your DNS. Re Problems with 6to4 Actually, I'm going to skip most of this and simply acknowledge it: Yes. 6to4 sucks. It's terrible and horrible. *Everyone* of low-to-moderate knowledge in IPv6 knows it. Use 6rd instead if you need that kind of tunnel; at least you'll know who to yell at if it breaks. Re Security Implications of Teredo: Yes, Teredo sucks, too. Disable it. Re 'Translation' (pardon the US-centric view, here) All major ISPs have deployed (or are in the process of deploying) native IPv6. Mobile carriers have deployed IPv6. Tunnels will be largely unnecessary. NAT will remain, but it will be more prevalent in IPv4 than in IPv6. Re 'Exploiting Transition Technologies' "Some systems (notably Windows) have support of trnasition technologies enabled by default." Yes. Disable Teredo. I'm not aware any other distro that enables a tunneling protocol by default. (skip benign material.) Re Application-layer protocols "A number of applications may leak IPv6 addresses: E-mail headers, P2P applications" As far as email headers, that's just as in IPv4. You can examine some folks' IPv4 RFC1918 topology by their email headers today, so don't tell me IPv6 brings much new to the table. As for P2P applications, this is actually a good thing; P2P applications can use what they learn for more efficient peer association. (skip the rest, as it's benign)
signature.asc
Description: OpenPGP digital signature
