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 harmful) for a variety of applications. > Global NAT works well enough With global NAT, anything you do that depends on port forwarding is broken. > 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. There's almost nothing you've pointed at so far that would have prevented backbones from IPv6 uptake...and the backbones dragged their heels long enough. IPv4 with expanded address bits would have been worse; IPv6 explicitly includes features intended to ease the strain on the size of a global routing view! > > 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. You call that code complex? (and I still don't know what 'ipvshit' is, except possibly one guy's pejorative description of IPv6) > Note OpenBSDs kernel which is very secure (unlike Linux whose > primary goal is function) I have no complaints about OpenBSD. > and has had just a few remote holes in well over a decade, one of > which was in ipv6 So OpenBSD, who you venerate, had a bug in its IPv6 implementation, and for that you view IPv6 as an abomination? Is that it? (Or is it because the guy who wrote the buggy code thinks so, and you venerate him? Because that seems plausible, too.) I like Linux, but I don't hold Linux (or any Linux developer) in veneration. I like Windows, but I don't hold Bill Gates, Balmer or any Microsoft dev in veneration. I like Android, but I don't hold Google or any Google employee in veneration. I dislike Macs, but I don't think of Steve Jobs as evil. > and which I had avoided without down time because I won't and what's > more shouldn't use ipv6 wherever possible Do you mean that as "I'll avoid IPv6 as much as possible" or do you mean that as "I won't use IPv6 in all places where it's possible to use IPv6"? If the latter, I'd agree; there are places you can use IPv6 where it probably won't make a whole lot of sense (i.e. on an HDMI cable, unless you have a particular need to provide network traffic to/from your TV). If the former, I'm afraid I still haven't seen a solid technical case against it. > and had actually removed it from the kernel all together. That's sensible; if you're not going to use code, remove it. > > If I am Trolling rather than simply trying to make people aware then > stating ipv6 is wonderful is Trolling just as much or more. IPv6 fixes things about the Internet that are currently broken by IPv4 address exhaustion. I try to point out where IPv6 fixes things, I try to clear up popular misconceptions about IPv6, and I try to help people understand a thing rather than simply fear it. If you take a highly competent IPv4 network administrator and drop him into IPv6 territory without ensuring that he has knowledge of IPv6 best practices and practical concerns, you're likely to get a broken network out of it. I try to help keep that from happening. The statements you've made that I regarded as trollish where were you made emotional statements and arguments without anything explanatory to back them up. In contrast, I've spent *hours* wading through the links you've thrown at me (without you yourself reading, I suspect), making point-by-point responses.
signature.asc
Description: OpenPGP digital signature
